× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi, I just have a few comments...

>
> 2. Up the TCP/IP send/receive buffers.  By default there are rather
> small.

I have to disagree strongly with this statement...   Each socket is
allocated 8k (by default) for both send and receive.   Since computers
are MUCH faster than networks, anything transmitting data en-masse will
fill up this buffer quickly, and then have to wait for the buffer to empty
out.

If you make the buffer size larger, then it will STILL fill up quickly.
But you'll have to wait for more data to empty out!    Instead of having a
pause long enough to send 8k, you'll have a pause long enough to send
500k, or whatever you set it to.     This wastes memory and causes
programs to unnecessarily time-out.

Increasing this buffer size really only makes sense if your CPU is slower
than the network, which it never is.

If the application calls for larger buffers, it can override this size
interal to the app.

>
> 5. Try setting the TOS parm of the IP interface to *MINDELAY.
>

I guess that's a possibility...   Though I'd think *MAXTHRPUT would be a
better choice.   *MINDELAY is better for something like the telnet
protocol where you're sending small amounts of data, but you want it as
fast as possible.   *MAXTHRPUT is for mass-data transfers like FTP where
you don't mind packets being grouped together and sent as one if it makes
the TOTAL transfer time shorter.

Though, I don't think many routers today still use these values, and the
application can override them if it wants to.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.