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

[freqmax]

20 Mbit/s on a local LAN seems slow.

[matt3k]

20 Mbit/s on a local LAN seems slow.

Great point...   must be an issue with the qnap nas.  That being said the xsurf should still see the same speed.

I will ftp to the pc and see if there is a difference.  Will also use a different switch.

Appreciate the help.

[freqmax]

A speed tip is to use a network card built for 1 Gbit/s on a 100 Mbit/s network in order to maxout capacity. Or 10 Gbit/s on 1 Gbit/s network etc.

[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.

[LoadWB]

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 this 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.

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?

[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.

[freqmax]

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.

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

[matt3k]

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.

Still an CS MKIII 060 @ 50MHz and 128MB of local ram, should produce much better results.  At least what your Warp Engine 040 @40MHz is giving you.  This performance is dismal.  

Could AMFTP and Ibrowse be lying to me, can't see where that would be possible so again I go back to the hardware.  

I tried booting as vanilla as possible, thinking it was my hacks, to make it go faster and it made no difference.  Wonder if the X-Surf is Defective? Nothing else could explain for it at this point.

Could you PM for the speed test you created?  What do I need for the other system?

[matt3k]

A speed tip is to use a network card built for 1 Gbit/s on a 100 Mbit/s network in order to maxout capacity. Or 10 Gbit/s on 1 Gbit/s network etc.

Interesting point, is it possible my GB Network is the culprit?  I suppose  could use a cross over cable for testing.

I'm using all Intellinet Switches and Router, don't know of any issue with them.

[LoadWB]

Interesting point, is it possible my GB Network is the culprit?  I suppose  could use a cross over cable for testing.

I'm using all Intellinet Switches and Router, don't know of any issue with them.

I have good results with Intellinet switches.  I was running a gigabit switch on the back-end of my virtualization platform on which I provide hosting.  That said, I have never had one fail full-out, rather they tend to die a little piece at a time.

[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.

[matt3k]

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

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

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

[Oldsmobile_Mike]

Nice performance!  Are there any updates for this card as far as if the module to activate the USB ports has been released yet, or an ETA?  "Two more weeks"?  :juggler:

[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.

[mechy]

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.



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



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.

It sounds as if we need a ethernet card with onboard cpu with large buffers to take the load off the 68060-i guess it would dma or take advantage of fast scsi when saving.
I have been following this thread and it has been interesting. i have not gotten a new x-surf card yet,but probably will soon.