At 02:44 PM 5/14/2004 +0800, zamri wrote:
Ray, Thank for your review,
> Right. Obviously (I hope this is obvious) you cannot use a source with a > 1.5 Mbps upload limit to test a 2 Mbps download ... unless, I suppose, the > 2 Mbps connection is running *way* below rated speed. You might do better > to find a public ftp repository (a Linux-distro mirror, for example) near > you and do some downloads from it.
Done, here the result : ---> RETR linux-2.6.6.tar.bz2 150-Connecting to port 2403 150 34078.3 kbytes to download [....] ############################## [....] 226-File successfully transferred 226 490.382 seconds (measured here), 69.49 Kbytes per second ftp: 34896138 bytes received in 492.34Seconds 70.88Kbytes/sec. ftp>
I'm using the public repository one that near my place at Malaysia. ( ftp://ftp.averse.lkams.kernel.org/ ) When i run traceroute, it was about 14 hop from my local LAN :
1 * * * Request timed out. 2 1 ms 1 ms 1 ms 202.185.xxx.xxx 3 4 ms 4 ms 4 ms 161.142.xxx.xxx 4 4 ms 4 ms 5 ms e0.sha15.jaring.my [161.142.236.16] 5 8 ms 7 ms 7 ms s4-1-2.bkj4.jaring.my [61.6.2.93] 6 27 ms 19 ms 23 ms 161.142.173.90 7 9 ms 9 ms 10 ms pos0-0.mlk90.jaring.my [161.142.25.86] 8 27 ms 19 ms 12 ms pos2-0.mea90.jaring.my [61.6.17.46] 9 29 ms 13 ms 12 ms fe-5-1-0.mea15.jaring.my [61.6.17.70] 10 15 ms 16 ms 19 ms 203.208.152.9 11 19 ms 31 ms 16 ms POS3-6.tp-core1.ix.singtel.com [202.160.250.9] 12 17 ms 30 ms 18 ms 202.160.250.54 13 27 ms 20 ms 23 ms PC2.commonwealth.singnet.com.sg [165.21.12.26] 14 27 ms 33 ms 20 ms 203.127.221.98
Is the result makes any sense for 2Mbps line?
It *could* "make ... sense", but it is unlikely to. From here in the USA, I got (on a DSL line that is nominally 384 Kbps download but that usually delivers over 1 Mbps) this result from the same site:
226 186.653 seconds (measured here), 161.00 Kbytes per second
30772389 bytes received in 186.89 secs (160.8 kB/s)So the site itself is probably not limiting you (unless it was busier when you tried ... I was one of 3 connections when I started). The speed limitation is either
1. In your router 2. In the P2P link between you and your ISP 3. Between the ISP and the Internet.
You can eliminate possibility 1 by testing with a host connected directly to the P2P link. Given your uncertainties about the router (due to your having a second, completely separate problem), you should do so. Testing the P2P line itself (possibility 2) requires control over the hosts at both ends of the line, something you don't have ... but if you eliminate the router as the source of the problem, I think you easily have enough evidence (this report plus the McAffee result, plus the evidence that moving from 1 Mbps to 2 Mbps actually slowed response speed) to ask your ISP to investigate.
> [...] > > > As to your Web-page problem ...
I'm not reviewing the specifics you posted because they suggest nothing to me. But if the ONLY change you made was the router substitution (I'm leaving out the speed "upgrade" because I cannot imagine how it would affect connections between your LAN and your DMZ), the problem almost surely has to be in the router somewhere. (If you made other changes and haven't mentioned them here ... well, what sort of help do you expect to get in that case?)
In this case, you're going to need help from someone who has made the same switch, something I haven't done. So I'll leave it to others to try to offer specific suggestions here.
[...]
[...]eth0 is connected to my staff network ( 192.168.0.0/24 ) and eth3 is connected to my student network ( 192.168.1.0/24 ) . Is there any how i could trace the source of collisions? Do you have any other suggestions or advice?
How many hosts are on the student network? Do they have usage characteristics that would cause high peaks? Is the interface 10 Mbps or 100 Mbps? Over what time period were the 6 million Tx packets sent?
I'm curious as to why the router sends only about 1% as much traffic (in packet count; about 10% measured in bytes) as it receives on this interface.
> > RX: bytes packets errors dropped overrun mcast > > 3229811836 726754647 0 0 0 0 > > TX: bytes packets errors dropped carrier collsns > > 310837687 6346146 0 0 0 2149416
This is unusual for a LAN that is (I would expect) mainly clients ... what is generating a very large number of very small packets on this network? (The RX results indicate an average packet size of 4 bytes, while TX is 48 bytes ... the TX value looks about normal but the RX value is down around the size of a ping packet. Could this LAN have hosts that are spewing out broadcast SMB packets, for example?
Collisions may just indicate high usage levels relative to capacity. So the first step really is a usage analysis. My questions above are a rough cut at understanding usage on this network.
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
