Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content count

  • Donations

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ajh499

  1. Right, Sorry for the delay, I've only just managed to get my hands on the HP laptop again. I had already tried turning RSS off in the advanced driver settings before you suggested it. I've now tried turning it off by using netsh. Neither way makes any difference. I guess I'll just have to try getting hold of Intel technical support, but I won't hold my breath on that one. Alex
  2. I have tried loading different different cores, it doesn't seem to matter which is loaded as long as one is. I'll have a go tomorrow at turning RSS off and running perfmon with a few more counters and seeing if anything weird shows up. The machines are both running the 32-bit versions of windows. The simplest test I've been doing is using the Network test option in Performance Test 7 from Passmark software to stream packets over a TCP connection from one machine to another, and watching the number of packet errors in perfmon. The reason I'm using this software is that I wanted to make sure that the problems still showed up when using third-party software rather than something I had written that may have had a bug in it. Also, it's easy for someone else to try the same software as it has a 30 day evaluation available. The packet size seems to make a difference. If I set the packet size to 3000 bytes, I get very large numbers of errors, but if I set it to 3072 (ie 3K), I get very few, if any errors. The MTU size is 1460 so neither 3000, nor 3072 is a multiple.
  3. I did run Wireshark without prime, but the CPU load of capturing the packets prevents the errors from occurring. Also for the test in the perfmon screenshot, I only run Prime95 on one core, that's why the CPU usage only goes up by 25%. It's maxing out one core of a quad core laptop. I know I'm getting too many errors to begin with, it should be practically nothing. The issue with the CPU only adds to the weirdness. Alex
  4. I've run perfmon, I think the image below shows the problem pretty well! As for Wireshark, there is a slight problem. Capturing the packets introduces enough load on the CPU that the packet errors do not occur. I'm not sure if it is a problem with the Intel network card, as the same thing happens with an ExpressCard adapter with a Marvell chipset. Alex
  5. Time to get on the phone/email HP and Intel about this and see what they say. I've already tried phoning HP technical support, and they were completely useless. I don't think Intel offer any support for notebook products, they just direct you to the manufacturer of the machine. I've had a go with Wireshark already, and I can see that every so often the TCP sequence number stops increasing for a while, then carries on again. I guess that is the point at which the data is being resent. I'll have another go with it tomorrow, but I think that the erroneous packets do not make it as far as Wireshark. Which doesn't really help very much.
  6. It indicates a duplex mismatch http://en.wikipedia.org/wiki/Duplex_mismatch Maybe your VxWorks device has problems with Full Duplex mode? Many embedded devices do have cheap NICs, often not gigabit rated. Sorry, the half / full duplex problem appears to be a red-herring. My fault. I don't think I explained what I'm doing very well. I'm not actually testing this problem most of the time using the embedded device, as it is quite complicated to test against and there is always the potential for bugs in our data receiving code. Most of the testing I'm doing is using the Network test from Performance Test 7 by Passmark software, and two computers (the HP laptop with the problem and a Dell desktop) connected back-to-back. I'm using this software as it is easy to use to show up the same problem on the HP laptop as we see with either our own test software on two computers back to back, or with the embedded device connected to the laptop with more complex software running. While I was trying out the half / full duplex options yesterday, I was forcing the laptop to the speed and duplex mode that I wanted, but leaving the other machine on Auto, apparently this was causing a Duplex-Mismatch. I've just tried it again, this time setting the speed and duplex of both machines and this time it works correctly, with no packet errors except at gigabit. This is with two computers back to back with some test software, however the embedded device needs gigabit as the data rate is far too high for a 100BASE network. I also tried out a 1m long CAT6 cable, and at gigabit it still shows packet errors when the CPU is not busy. Any more suggestions? Anyone? Alex
  7. IP checksum makes no difference either Of course there is always a chance of packet errors, but I'm seeing hundreds, or even thousands of errors per second, when the CPU is doing nothing. Then no errors at all when the CPU has a bit of load on it. I'll check out what the cables are that I've tried and make sure at least one of them is Cat 6, but I don't think it's that. The connection should be as "Good" as it can get, two machines with gigabit cards connected back to back with a 2m-ish long cable. I could understand a connection problem if the same cable lost packets on another machine, but it doesn't. Or, if it was something to do with the laptop's built in network adapter, but I've tried two different cards and both have the same problem. And why does loading the CPU stop the packets from apparently containing errors? Very, very odd!! Alex
  8. Thank you for your suggestions, I've just given them a try. TCP/UDP Checksum Offload makes no difference whether it is enabled or disabled. I've used a variety of cables when testing this, and they don't seem to make a difference and all work with a different computer as the receiver. Or sending from the laptop to another machine, for that matter. I don't think that the link speed is dropping due to the CPU being loaded as the number of bytes sent and the average transfer rate are very similar regardless of the CPU loading. I guess it would actually be slightly lower due to the retries of the discarded packets, but the readout in Performance Test is not showing it in enough detail for that. The one thing that did seem to make a dfference was the link speed and duplex setting. I tried all combination of half and full duplex at 10, 100 and 1000 MBit/s (except for 1000 Half duplex as it is not an option). The tranfer rate would be the same at the same speed setting, but the half duplex mode would not have any discarded packets, but the full duplex modes would. 100 BASE - Full Duplex discarded more packets than even Gigabit. The trouble is we need around 200MBit/s to receive the data from the embedded device, so we have to be able to use Gigabit. I'm still very confused Alex
  9. The embedded device runs VxWorks, I think, but I might be wrong. The Vista laptop has SP1, the XP one is SP2. I think the packets arrive late because they have to be resent due to the first attempt containing an error for whatever reason. All devices used in trying to find the cause of this problem are gigabit The laptops have been tested plugged in and running on battery, it doesn't seem to make any difference. The latest version of Prime95 will load all cores by default. However only one core (doesn't seem to matter which) needs to be loaded for the packet errors to disappear.
  10. I've tried it both with a switch between them and by simply connecting back to back, there are no other devices on the network. Both ways of connecting display the same problems.
  11. Hello everyone, I hope someone can help me with a very strange problem. I have two brand new HP EliteBook 8730w laptops, with quad core processors. One is running Vista, the other has XP on it. The problem I am having is that when streaming data packets over a TCP connection from either an embedded device or from another computer running some test software, the laptop either loses some of the data, or it arrives late after a number of retries. This is using the built in Intel gigabit ethernet card, not the wireless. I'm seeing errors in the received column if I do a netstat -e. And I see "Packets received discarded" in Windows Performance Monitor. The really strange thing is that if I run something other than the data receiver program, either a bit of test software written by me, or something like Prime95, so that the CPU is loaded, suddenly the data errors stop and all the packets are received correctly. It doesn't matter which of the two laptops I use as the receiver, both have the same problem. I've tried different network drivers and made sure all other drivers are up to date. The laptops already came with the most up to date bios. I've even tried using ExpressCard and USB network adapters instead of the built in Intel card with no luck. Has anyone ever seen anything like this Any help would be greatly appreciated. Alex
  12. Hotfix and Application Integration?

    Thanks, That guide looks quite useful, if a bit long-winded. I'll give it a go. But what about adding applications to the image? The way that nLIte worked for XP was really useful. Nuhi, is any of this stuff planned for the future? Alex
  13. Hi, Are there any plans to include hotfix and application integration into vLite as they were in nLite? Or am I being blind and it already works!!! These were the most useful features for me. Reducing the size of the installation was only a secondary benefit of nLite. Thanks Alex