Hello, All!
The question is kind of out of Keil's scope but would appreciate if someone will giv an idea to try.
So, I am using ST10 running on phyTEC core, and the core operates CS8900A Ethernet controller, I am using 3d party TCP/IP stack (CMX) along with my own modules. On s/w side I am sitting under MS Windows XP Pro V.2002/SP2. Laptop is Dell D610 w/ built-in ethernet adapter Broadcom NetXtreme 57xx. An application on windows side uses sockets library wsock32.lib.
The f/w works just fine if I am connected to my internal laptop's ethernet adapter. No hassle. As soon as I am using Belkin USB-Ethernet adapter, namely F5D5050, I am experiencing a drop in bulk TCP speed. Be precise, drop is of factor of order x5, i.e. something is going really wrong. I have to use the 10BT Ethernet in case of phyTEC. First, I checked f/w simply by replacing my ST10 device with 3d party device (NetBurner's network-enabled CB34-EX module working at 100BT and built on Coldfire MCF5234). In this case I have the drop around factor of ~ x300 (!) - think, because of 100BT Ethernet and because of pronounced power of MCF which makes the drop more visible. In other words, when using Belkin adapter I have only 5...10 kBytes/s, which is shame.
The adapter is supposed to work both with 10/100 Ethernet and I _did_ verify this fact by using independent refence: the web browser. I have found that the IE6.0 has pretty good effective download rate of about 500 kBytes/s for a large files even if working through the Belkin USB-Ethernet adapter. As far as I know FTP is built over TCP, so the independent test should be adequate. I also checked other USB devices I have connected to my laptop, and disconnected them - no difference, the TCP stress test results remain the same. Changes in several settings on Belkin adapter side ("properties" under Windows, however not documented) did not help. So, I should not believe this is USB2.0 who is the bottle-neck.
Additional facts: ARP cache get cleaned up before each test (MAC/IP fitting is monitored before running the test). Either adaptor disconnected and disabled if another one is in use, i.e. the only single adapter is active at the given time. F/w gets its reset before the test. Firewall and other secure stuff (up to my knowledge - what can be missed, or what can affect the performance?) is off during the tests. To remember - the internal ethernet adapter works fine with my two test systems, ST10 and MCF. So, should be some feature in a way how the IE communicates with USB/Ethernet driver?? Should mention, the test f/w just sends bulk data (random) to the s/w side in payload packets w/ size 1460 bytes or less.
Any idea?
Regards, Nikolay.
P.S. To be not confusing here is what I mean: - non-blocking scheme is expected to increase internal f/w responsiveness to different net events running asynchronously, so might have impact (how strong - this is an open question) on communication w/ external ethernet counterpart - "no push" stands for a mechanism where not all write() operations result in "quasi-immediate" send() packet operation, i.e. there is a bufferization (a-la Nagle's algorithm)
--- Nikolay.
Hello,
Here is an update:
I tried Linksys USB200M V.1.2 USB-Ethernet adapter, and problem has gone. I just installed the supplied driver, put fixed IP addresses, turned off firewall & secure stuff for my isolated network for this particular adapter (unnesessary net services also put off), nothing else done in terms of tuning. E.g. adapter's h/w setting just left go default. Finally I've got my stable Ethernet stream (e.g. 100BT out of CB34's Coldfire pumps ~2.5 MBytes/s via Linksys USB200M). So, I am throwing away the Belkin adapter for now; as fact, have two simultaneously running Ethernet adapters: laptop's internal adapter to access the world, and the isolated P2P network "Lynksis-<my test device>" to get tests done. Also, at the same time have USB-232 adapter communicating at 115.2 kb/s + wireless mouse, all running in parallel at the same time.
P.S. Would be interesting to find a root cause of the initial issue however not sure it is still burning question today, especially if regard the information re: 5-year-old USB1.x chip ADM8511 used in Belkin F5D5050 design.
The moral is: always try several manufacturers...
A packet sniffer like Ethereal will likely provide insight into the root cause of the problem. I would not just throw the device away and blame it on the manufacturer. I'd say the moral is: use the right debugging tools.
Hello!
Yes, I am planning do the analysis as time allows and now just evaluating different beings w/ intentional minimal touch of 3d party TCP stack providers, i.e. doing kind of "exterior", or "phenomenological" estimation of off-the-shelf networking f/w libraries.
What would you recommend as a better tool: Ethereal or Wireshark, or somewhat else?
Thanks, Nikolay.