X-Surf 100 - Best TCP/IP for Speed?

[olsen]

You can't trust propietary stuff. Add to the mix the mandatory US goverment mandated backdoor.

Not sure if there is such a thing.

From what I gather, in most cases it would be unnecessary because the lack of robust security in the firmware is a perfectly adequate substitute which also provides for convenient plausible deniability: hey, that was a bug/typo/manufacturing test.

Getting a useful backdoor into the code which is not easily discovered or used by other people who are up to no good (poster child: wiretapping functionality in Ericsson switches used by Vodafone in Greece enabled and used by persons unknown; discovered by accident in 2006) is difficult. The complexity of the task will almost inevitably lead to the backdoor being discovered.

[olsen]

@Olsen

Installed Roadshow Demo.

Wow, wow, wow, and wow.  350,000 cps peek and always above 300,000.

Would that be local network traffic or internet traffic?

I still think that this figure is too low for the X-Surf 100.

I can get that much out of plain Ariadne on a foggy day with drizzle and light snow (in fact, in my tests Roadshow squeezes as much out of the Ariadne as you possibly could expect from a 10 MBit/s Ethernet card: more than 900,000 bytes per second).

The X-Surf 100 should peak somewhere above 2.2 MBytes per second, and unless your internet connection is very poor in terms of throughput, you should be able to get at least 1.5 MBytes per second downstream traffic out of it, probably more.

Ok, so now I need to test smb shares on the nas and samba.  Assuming those work, and you have yourself another customer.  Don't know what Easynet is having trouble with but, it simply will not perform, was just going to use Miami and hang out at 200,000.  Not any more, your product screams...

Well... I still think there's something fishy going on. It's nice to read that Roadshow performs better for you than both Miami and AmiTCP do under the same circumstances, but the throughput figures are far from what the X-Surf 100 is capable of.

Incidentally, the Roadshow "DEVS:Internet/servers" contains ready-made entries for smbd and nmbd, which are commented out. If you have everything installed in Samba:, then everything you need to do in order to give Samba a spin is to remove the leading '#' characters in the last three lines of the file.

[olsen]

Did a bit more work to test it properly.

Switched to FTP using my NAS in my LAN.

Much different story.

Miami with SANA -  900,000 cps
Roadshow demo - 1,200,000 cps
EasyNet -          -1,500,000 cps

Seem like with FTP EasyNet is the fastest.

Out of the box Roadshow is configured to use resources conservatively, like it used to be back in 1995 when the 4.4BSD TCP/IP stack was released which Roadshow is based upon.

You can tweak the performance further if you would want to. Ask me how :-)

That still seems slow for a 100mb NIC in a Lan.  

Yes and no.

No, because your Amiga's CPU has to do most of the heavy lifting when moving data between the network and your computer. This causes so much load that the amount of data that can be transferred will be limited by it. This is one reason why the 100 MBit/s NIC will only deliver a fraction of the theoretical bandwidth possible.

Yes, because you are still below the 2 MByte/s which the X-Surf 100 should be able to deliver on your system (provided that you have proper Cat 5 cabling, an Ethernet switch which is fast enough, supports bidirectional traffic, and the server you are testing with can send/receive data fast enough).

Easynet has to have some issues, perhaps it is in the dns setup.  It is a bit convoluted to my thinking.  

Any ideas???

Even if the DNS setup may look convoluted (I have no idea if it does; I never used EasyNet), it is unlikely to be the reason why the available network speed is not as high as expected.

The DNS servers configured are typically consulted once before a connection is established, and once the connection has been established, and data is being exchanged, the DNS server configuration is completely irrelevant.

Picture it like this: DNS is like a map you consult at the beginning of a road trip. You figure out where you want to go (and maybe take notes). While you are on the road, you will follow the route suggested by the map. And while you are traveling to your destination, it no longer matters how long you looked at the map, how many times you looked at it, or if you checked several maps instead of just one. What matters is the distance you need to travel, and possibly if there is construction work, detours, or if you run out of gas.

[olsen]

Man this site is terrible lately.  It took me 7 times of logging in to get here...

@Olsen

Please share the speed tweaks for Roadshow!

You can try three things (in order of how likely each change will land you in hot waters):

1) Change how much data may be sent in a single Ethernet packet
2) Change the number of I/O requests which the network interface uses
3) Increase the sizes of the TCP transmission buffers

The first is easy enough. Before you start Roadshow, enter the following command in the shell: RoadshowControl set tcp.mssdflt = 1500

You can make this tweak permanent with the following command, entered in the shell: RoadshowControl save set tcp.mssdflt = 1500

The default for this setting is 512 bytes, by the way. Which is how this used to be in 1995's Internet.

The second involves changing the network interface configuration file which you set up for the X-Surf 100. Let's say the configuration file is in "DEVS:NetInterfaces/X-Surf-100". Then you would open it in your text editor of choice and look for the following lines:

#iprequests=32
#writerequests=32

Remove the # characters and increase the numbers a bit, say by 16:

iprequests=48
writerequests=48

Save the changes back to disk and restart Roadshow (or your Amiga - whatever is more convenient).

Word to the wise: this tweak may not make much of a difference with the X-Surf 100. Even pumping up the numbers to 64 and beyond may not make a difference, performance-wise. It will just consume memory that might be put to better use.

The default values for the I/O requests are 16 each. Each I/O requests consumes 1500 bytes.

The third involves increasing the TCP receive and send buffers. To try this, enter the following commands in the shell before you start Roadshow:

RoadshowControl set tcp.recvspace = 65536
RoadshowControl set tcp.sendspace = 65536

The default values for both buffers are 32768 bytes, by the way.

To make these tweaks permanent, use the following commands:

RoadshowControl save set tcp.recvspace = 65536
RoadshowControl save set tcp.sendspace = 65536

Word to the wise: dialing up these buffers is not recommended unless you have far too much otherwise unused memory available. If you increase the buffer sizes, then each single network connection which your Amiga opens will eat up that much memory, e.g. if you pick 65536 for sending and receiving data, that will commit 128 KBytes to each connection.

Note that increasing these sizes will probably make no difference at all with the X-Surf 100.

Note, too, that increasing these sizes beyond a certain point will render your TCP/IP stack "combat ineffective" because it will consume so much memory that it won't be able to do anything at all. Remember: you're playing with fire if you tweak these two settings. You have been warned!

In case you do get yourself into trouble because you used RoadshowControl save set for any of these settings, you can remove these changes again with the following shell command: Delete ENVARC:Roadshow ALL

Reboot your Amiga after you have deleted these environment variables.

[olsen]

Great point...   must be an issue with the qnap nas.

Um, not really.

The problem is that the X-Surf 100 is so fast that your Amiga will spend almost all CPU time just to feed new data to the card, or transfer data from the card to the TCP/IP stack.

If your Amiga were faster, then the transmission speed would be higher.

The X-Surf 100 is literally waiting for the Amiga to catch up to what it is doing, while the Amiga is already running at full tilt.

[olsen]

Could this method be used to set up jumbo frames?  How would Roadshow, or a 50MHz 68060 Amiga, react to frames up to 9000 bytes?

No, this tweak has a different purpose.

It changes what is known as the "TCP maximum segment size". A TCP segment may become as large as the IP datagram permits, which it fits into. The IP datagram's size is limited by the frame size of the transmission medium, and by the maximum datagram size the intermediary systems in the Internet are required to support. If I remember correctly, that maximum datagram size was 536 bytes in 1995. Which is why Roadshow has that curious 512 byte limit for the TCP maximum segment size.

In this case, the transmission medium is Ethernet, which supports frames of up to 1500 bytes in standard mode (no jumbo frames). By tweaking how large a TCP segment may become, the TCP/IP stack will make better use of what Ethernet can do. Even if you transmit less than 1500 bytes per frame, Ethernet will still spend as much time to transmit the data as if it were 1500 bytes in size. So, why not use that time to send data instead of filler?

Jumbo frames are a different matter. The network interface has to support them, and the driver, too. If you can get both to work together, the next step would be to dial up the TCP maximum segment size.

I do not know if there is an Amiga Ethernet card which supports Jumbo frames.

[olsen]

I don't recall any 512 byte limit on IP packets in 1995. Perhaps for modem users, but certainly not for Ethernet connections routed to the backbone. I think this is a misunderstanding.

No, this is not a size limit on packets (actually, IP datagrams). It has something to do with how the TCP protocol works, specifically how it deals with lost data or data which does not arrive in the exact order in which it was sent. There has to be a minimum required fragment size for all intermediary systems which carry TCP traffic for the protocol to work (same goes for UDP, too).

The conservative minimum requirement was 536 (or 576, I don't remember at the moment) bytes. If IP datagrams were larger than this, then intermediary systems could break them up, if necessary, thereby increasing the overhead for transport. The minimum requirement controls how small a fragment may become during transit, worst case.

The TCP/IP stack which Roadshow is built upon was released as part of 4.4BSD-Lite2 in 1995, and in that year the infrastructure that made up the Internet looked different from how it is today.

I'd say that you can use 1500 TCP segments today and won't have the individual IP datagrams broken up during transport.

But then tweaking this parameter in the Roadshow configuration isn't such a big deal. When establishing a TCP connections both peers will negotiate the maximum allowed segment size and settle on the lower value of both sides. If you allow 1500 byter per segment and your peer insists on 576 byte, then it will be 576 bytes.

I recently checked out how large that maximum segment size value actually is in practice, and I found that in my tests that 1500 bytes were accepted without complaining.

Anyway, looking at TCP traffic a packet limit at 1400 .. 1420 bytes could be worthwhile to try.

It's probably not worth the effort. The relevant protocols for data transport negotiate the parameters they need. It's just that today, you remove some of the restrictions of the past decades and not have them degraded again. Pick the largest number that works (say, 1500 bytes), and the TCP protocol negotiation will adjust to it.

[olsen]

Update for the group:

Using the tools that Olsen recommended my speed is where it should be:
Tcpspeed results:

Miami - 1,280 MB Per Second
Easynet - 2.185 MB Per Second
Roadshow - 2,066 MB Per Second

This about matches the performance figures reported by Jens Schönfeld an others. Good

I hope you can finally stop worrying about the hardware being defective, or your network settings to be the source of trouble. Your "X-Surf 100" seems to be working exactly as it should do.

Interesting that Ibrowse can barely get 80,000 downloading with easynet, and roadshow cranks out 350,000 cps.

Glad to hear that all the hard work I put into making Roadshow does make a difference

Thanks again Olsen.  Good call on the 2.2 max for the card in my system.  You were spot on!

2.2 MBytes/s is at the top end of the scale, for a "real" Amiga with 68060 CPU. I would expect that if you could make the 68060 go faster (hypothetically speaking!), then the throughput would increase further.

[olsen]

Some other testing items, so others can save the headaches...

I increased iprequests to 77 for Roadshow and used all the other tweaks Olsen recommended, and Ibrowse really flies (relatively speaking), I went from 350,000 to over 800,000.  I will try increasing more to see if I keep gaining.  The tweaks don't make a real difference outside of Ibrowse 2.4.

I still can't get roadshow to beat easynet with tcpspeed and ftp.  Any ideas or suggestions?    

Sorry, no. I still do not understand how these results come together.

Olsen,  Did you ever add in lpr.device settings to roadshow?

I had not used "lpr.device" in years, so I went back to the documentation and found that you do not need to configure the TCP/IP stack to support "lpr.device" functionality.

All you need to do is set up the printer preferences to use "lpr.device" in place of "parallel.device" and set the environment variables which enable "lpr.device" to find the printer it should be talking to. That's pretty much it.

Roadshow will carry the data to the printer, but there is nothing in Roadshow which needs to be set up specifically for "lpr.device".

[olsen]

I ran some tests with tcpspeed as my x-surf100 is up and running in z3 mode.

Genesis 849 kb/s
RoadShow 685 kb/s
Miami 422 kb/s

Roadshow is configured with the suggestions earlier in the thread. (Which made a little speedup) I was hoping for higher transfer rates though as i see the results of other users.. However, i have some limitations in my system:

Im using an a4k/a3660/50mhz which is practically running on zIII memory (FastlaneZ3) as my 8mb on the mb is eaten up by the os.
Will the zIII mem performance affect the transfer rates this much?

I knew genesis could be faster than roadshow, but not that much.. and Miami?! come on!!

Cheers!

I could get more than 900 KByte/s out of Roadshow on an original "Ariadne" card (Zorro II, 10 MBit/s Ethernet, no full-duplex support), on my A3000UX with a 50 MHz 68060 CPU.

I would expect the XSurf-100 to do much better by comparison.

[olsen]

Don't think I've ever felt the need for a Roadshow GUI. But we're all different

I'm not.