Need Help resolving Speed-test Warning messages

[curious guy]

Hi...just hope i'm not bugging you here,since this is my 1st post in here after all...
I 'm running XP and I have a PPPoA adsl connection,
my ISP is (...supposedly) giving me a capacity of max 768 download/192 upload.
Problem is,I've done some tcp/ip and speed tests,
but I'm having trouble interpreting some of the "Warning" results...

a)I always get this warning:
Increasing the client's receive buffer (47.0 KB) will improve performance.
What value should I look for in the registry?
I searched for strings like "recv","buf*" etc.,but didn't found anything,
at least that seemed relevant with TCP/IP settings...

b)I always get this warning message in the S2C analysis:
Excessive packet queuing detected: 93.46% (or 92%, 96% and so on...)

c)I occasionally(but not always) get a warning message about "Duplex Mismatch",
which no matter how much I've googled,
I really cannot understand what in the world I am supposed to tweak to fix it,
is this a setting in the router,in the tcp/ip stack of XP,
or is this a problem with my ISP to whom I should complain about?

Here's my configuration and the test results,I have underlined the "annoying" parts.
Once again,forgive me if I have overwhelmed you with my questions,
just trying to understand/learn what's going on in here...

------ SG Speed Test ------
TCP options string = 020405b40103030001010402
MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.
Default TCP Receive Window (RWIN) = 48180
RWIN Scaling (RFC1323) = 0 bits
Unscaled TCP Receive Window = 48180

bandwidth * delay product (Note this is not a speed test):
Your TCP Window limits you to: 1927.2 kbps (240.9 KBytes/s) @ 200ms
Your TCP Window limits you to: 770.88 kbps (96.36 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON
Time to live left = 56 hops
TTL value is ok.
Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 00000000 (0)

------ Web100 Detailed Analysis ------
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client-to-server [C2S]) . . . . . 162.0kb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 597.88kb/s

Cable modem/DSL/T1 link found.
Link set to Full Duplex mode
No network congestion discovered.
Good network cable(s) found
Normal duplex operation found.

Web100 reports the Round trip time = 610.91 msec; the Packet size = 1460 Bytes; and
No packet loss was observed.
C2S throughput test: Packet queuing detected: 3.73%
S2C throughput test: Excessive packet queuing detected: 93.46%
This connection is receiver limited 92.38% of the time.
Increasing the client's receive buffer (47.0 KB) will improve performance
This connection is network limited 7.48% of the time.

Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgment: ON
RFC 896 Nagle Algorithm: ON
RFC 3168 Explicit Congestion Notification: OFF
RFC 1323 Time Stamping: OFF
RFC 1323 Window Scaling: OFF

[trogers]

Cable modem/DSL/T1 link found.
Link set to Full Duplex mode
No network congestion discovered.
Good network cable(s) found
Normal duplex operation found.

Web100 reports the Round trip time = 610.91 msec; the Packet size = 1460 Bytes; and
No packet loss was observed.
C2S throughput test: Packet queuing detected: 3.73%
S2C throughput test: Excessive packet queuing detected: 93.46%
This connection is receiver limited 92.38% of the time.
Increasing the client's receive buffer (47.0 KB) will improve performance
This connection is network limited 7.48% of the time.


Occasional duplex mismatch, high latency, data packets queuing for both upload (C2S) and download signals(S2C). C2S means client to server and S2C means the reverse.

This shows a problem in the quality of your signal. The cause could be a fault in the NIC, or signal device such as router, modem or in your cable line.

I would also try to eliminate the cause to be electromagnetic interference first by ensuring the modem and router are not placed near to each other or to other electrical device, esp cordless phone.

EDIT: Receive buffer in the test report means the same as TCP Receive Window in the TCP Analyzer and Optimizer.

[curious guy]

Thanks,trogers!:thumb:

That was a great time-saving to me...after hell of a "googling",
I also pretty much understood that it must have to do,(at least to some extend),with my NIC,
it's a Realtek 8139,I'll try updating drivers and see if that changes anything...
And you were more than right...
I guess that someone should have kicked kick me in the ...(filtered) for this:
my splitter was very close to my UPS...router and modem also very close one to each other.

I'll bug you with two more questions,to manage to narrow the problem:

a)(Again,my fault for forgetting to mention it):
My connection is actually ADSL over ISDN...
meaning the router is connected through the splitter to the ISDN modem.
Could this also be a major "problem in the quality of the signal",or would it be minor?
If so,should I be searching for tweaking the ISDN modem's settings,
or better just change the whole system to "pure" ADSL?

b)I found many contradictory statements over the Net regarding this one....
some people claim it's better to set the NIC in Auto-Negotiate mode,
while others prefer having it in Full-Duplex 100 Mbps.
But since I'm definetely not...certified by Cisco :)
what I want to know is,can I test both settings without a risk of serious "ill effects",
say,my router/motherboard/hard disk gets...fried?

[trogers]

Answers to your questions:

a) I would leave this to a later part after eliminating the easily rectified possibilities as the cause of bad signal.

b) No, manually setting your NIC to 10 or 100 Mbps full-duplex mode will not fry the innards of your hardware. But doing so may actually make your link into a half-duplex mode. See this for more:

http://www.cites.uiuc.edu/network/autosense.html#consequences

[curious guy]

He-he,just found a similar post here in SpeedGuide...
so as far regarding the "NIC question",
I pretty much already had got your answer :nod:

http://forums.speedguide.net/showthread.php?t=194574

What can I say-once again,a big thank you for spending your time,trogers...
wish I could somehow pay you back,
I spend so many hours reading guides,mailing lists or code in the Net,
and sometimes my mind just gets so overwhelmed by info,
that even if the answer is in front of me I 'm not in a position to figure it out...
And even more thanks for this link,
main page pretty much leads to a lot of good stuff for me to dig and learn,
(as said,"curious guy"):
http://www.cites.uiuc.edu/network/index.html

[trogers]

Glad to be of assistance. I have been helped by seniors in this website and am please to pass on what little I know to other members. Hope to continue learning from a curious guy like you too, as the technology is growing by leaps and bounds.