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

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

[matt3k]

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?    

Olsen,  Did you ever add in lpr.device settings to roadshow?  If roadshow works with my network printer I will pull the trigger on it.

Thanks to everyone for the help...

[matt3k]

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.

Let us know if you pull the trigger!  Even with the cpu pegged, the miggy is multitasking great.  

My hacks list that I have had the best luck with:
1. Executive - seems better overall when multitasking while playing mp3's, accessing the network, and other misc stuff.
2. Quickrom - seems to give a bit of performance in general.
3. Quantum - went back to using it after commenting it out 10 years ago.  Seems stable, not performance impressions yet.
4. Using P5 060 Libs.
5. Using Oxypatcher

These hacks 'feel' faster, but I don't have any numbers to back it up...

What do you use for hacks?

[danbeaver]

The lpr.device works with every stack but AmiTCP v3.  In the case of Roadshow, it works great and switching printers is as simple as changing the ENV variables.

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

[matt3k]

Just some follow up to share:

1.  Changes the requests in the x-surf-100 dev file - seemed to give a boost, still looking for the best number.  Currently using 77 and see a bit of an increase of 32.
2.  Like you said in your warning, I also don't recommend changing the buffers to 65536.  It created issues with copying large files accross the network.  The transfer would lock.  The default 32768 works perfectly.

 

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.

[mechy]

Nice work on that Matt. It seems you stumbled on the ideal settings. Have you tried amitrade center for ftp. I dont know if its any better/faster than amftp or amiftp etc.

i was wondering are you using the MKIII scsi on your system? good scsi over ide would probabaly make a difference in speeds you see. assuming you are testing transfers to drives and not to ram.

[matt3k]

Even a broken clock is right twice a day:).

Yes, using the SCSI to Acards SCSI to SATA converter and a SATA SSD.

I will try Amitrade, I think I had trouble with it though....  Will let you know.

As a quick update, if I copy huge files from my network it will still lock up occasionally on big files only.  This isn't frequent, and I not sure if is roadshow or some other program like executive or smbfs.

Will keep you posted.

Matt

Nice work on that Matt. It seems you stumbled on the ideal settings. Have you tried amitrade center for ftp. I dont know if its any better/faster than amftp or amiftp etc.

i was wondering are you using the MKIII scsi on your system? good scsi over ide would probabaly make a difference in speeds you see. assuming you are testing transfers to drives and not to ram.

[mechy]

Even a broken clock is right twice a day:).

Yes, using the SCSI to Acards SCSI to SATA converter and a SATA SSD.

I will try Amitrade, I think I had trouble with it though....  Will let you know.

As a quick update, if I copy huge files from my network it will still lock up occasionally on big files only.  This isn't frequent, and I not sure if is roadshow or some other program like executive or smbfs.

Will keep you posted.

Matt

If you have trouble with amitrade center its usually a missing or wrong mui lib.(or so memory thinks so check the docs if this is the case.

i was working with rc-ftpd with someone who had problems with large files also,it ended up being something in the unofficial boing bags 3&4 causing it, dropping back to original BB1/2 solved it, never did figure out what it was. Not sure if this applies to you or not. It could also be something with the filesystem you are using also.

[matt3k]

If you have trouble with amitrade center its usually a missing or wrong mui lib.(or so memory thinks so check the docs if this is the case.

i was working with rc-ftpd with someone who had problems with large files also,it ended up being something in the unofficial boing bags 3&4 causing it, dropping back to original BB1/2 solved it, never did figure out what it was. Not sure if this applies to you or not. It could also be something with the filesystem you are using also.

Will look at the MUI Libs, but I think it 80000004'ed before it even got to that point.  Thanks...

I have BB2, had issues with BB4 and my Delfina setup...

Thanks for the suggestion, I used FTP to copy the entire file over.  Has to be SMBFS limitation somewhere...  Man I wish someone would update SMBFS to modern levels... Getting more limiting as time goes on.  Would be a great additional bonus if someone fixed the filesystem to work with large files...

[touringsedan]

My results with my new X-Surf 100.
A3000 WB3.9 BB4
Cyberstorm 68060
Genesis
Ibrowse http transfer.

I average about 750,000 cps.

I must open 3 concurrent transfers to reach the max transfer.

Going to try FTP to see if that moves faster, each IBrowse network process is using 7-9% of my CPU (3x), but once all processes reach 95% it peaks.

Shame it doesn't offload the checksum to the card as stated earlier, that seems to be the achilles heal of it all.

[danbeaver]

A base and random file transfer rate in cps is not a fair way to evaluate NIC card transfer speed, one needs to control all the hundreds of other variable factors that impact that number.  I would go with the card's designer recommendations that AmiTCP with his tweaks gives the best performance.  His testing was in a controlled environment setting where he limited the random variables.

[freqmax]

The catch is that real life usage isn't laboratory conditions..

[danbeaver]

The catch is that real life usage isn't laboratory conditions..

In that case, numbers mean nothing and you should go with intuition on TCP stack decisions and not bother quoting any numbers.

[freqmax]

It means one should try a variarity of situations to test. Even the Monty carlo method comes to mind.

[danbeaver]

It means one should try a variarity of situations to test. Even the Monty carlo method comes to mind.

And your validity comes from where?  A guess? A feeling?  

You can't account for the hundreds of variables that affect performance that way.