On 11/24/2015 03:26 PM, heyjoe wrote:
>
>> How about getting a LAN trace of the wget attempt so we can see if
>> something looks really odd. Use a command like this, then post the
>> output
>> somewhere:
>>
>>>
> Code:
> --------------------
> > >
> > sudo /usr/sbin/tcpdump -n -s 0 -i any -w /tmp/tcp80.cap port 80
> >
> --------------------
>>>
>>
>> The resulting /tmp/tcp80.cap file could be interesting. Please
>> compress
>> it before posting it somewhere for us to fetch.
>
> Ok, I have done this running the same wget for the same iso:
>
>
> Code:
> --------------------
> wget -O- http://mirror.leaseweb.com/opensuse/distribution/13.2/iso/openSUSE-13.2-DVD-i586.iso > /dev/null
> --------------------
>
>
> I let it run for about 30 seconds. I have compressed the result with:
>
>
> Code:
> --------------------
> 7z a -t7z -m0=lzma -mx=9 -ms=on -md=128m -mfb=273 tcp80.7z tcp80.cap
> --------------------
>
>
> The output is about 200mb. After uncompressing it you will see a file of
> about 246mb. I have uploaded the 7z file to Google Drive here:
> https://goo.gl/p7xzxm
>
> BTW something more on this: About 3 hours ago I suspended the laptop to
> sleep. When I came back and started the wget per your instruction it ran
> smoothly at 11.2mb/s (full 100mbps) for almost 20 seconds after which
> the speed fell down to about 40kb/s, then I stopped it. I also notice
> that usually each time I run wget the initial 0.5-1 seconds give a speed
> of about 100kb/s and then it suddenly falls to the magical 25kb/s.
>
> As I am typing this I am running a third test and it is downloading the
> iso at full 11.2mb/s (for 2 minutes already and not slowing down). Now I
> stopped it, and ran it again - variable speed between 25kb/s and 1mb/s
> for a short time, then dropped again to 25kb/s and stays there forever.
> After I leave it for a while and test again - I get 11.2mb/s and so on.
>
> This inconsistency is really strange.
Have you tested with any other URLs? Looking through the various posts
you seem to be always trying the openSUSE ISO; have you tested with
something that will definitely be on another server? Perhaps something
like Java, or another SUSE Linux Enterprise Server, or something from SUSE
Studio’s list of pre-build appliances?
Trying your command here gave me good output, but I’m hitting a different
IP than you from my home:
--2015-11-24 16:22:27--
http://mirror.leaseweb.com/opensuse/distribution/13.2/iso/openSUSE-13.2-DVD-i586.iso
Resolving mirror.leaseweb.com (mirror.leaseweb.com)... 209.58.135.187
Connecting to mirror.leaseweb.com
(mirror.leaseweb.com)|209.58.135.187|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4624220160 (4.3G) [application/octet-stream]
Saving to: ‘STDOUT’
- 100%=======================>] 4.31G 110MB/s in 46s
2015-11-24 16:23:14 (95.8 MB/s) - written to stdout [4624220160/4624220160]
Using the IP address you hit still completed, though much more-slowly; it
was still definitely in a range above yours through to the end of the
transfer.
--2015-11-24 16:24:26--
http://37.58.58.140/opensuse/distribution/13.2/iso/openSUSE-13.2-DVD-i586.iso
Connecting to 37.58.58.140:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4624220160 (4.3G) [application/octet-stream]
Saving to: ‘STDOUT’
- 100%=======================>] 4.31G 19.5MB/s in 4m 3s
2015-11-24 16:28:29 (18.1 MB/s) - written to stdout [4624220160/4624220160]
Going back to the LAN trace, things look great for, as you mentioned,
quite a while. The throughput is as it should be on a connection capable
of the speeds you said, but then a lot of out-of-order acks and
duplicate-acks show up twenty-one seconds into the transfer. For a while
the system appears to keep trying the higher rate, though that is
eventually abandoned and the system drops down to an abysmal rate, and it
seems like the server side (meaning anything upstream from you) is sending
the packets much more-slowly; note that with a trace taken ONLY from one
side, the problem could be that the ACKs are slow getting back to the
server, so the server’s slowness is because something is slow telling it
to continue.
To simplify things, have you tried plugging your laptop directly into the
mikrotik router? Maybe you said you did, but I cannot find it. Even
better, could you plus your ISP’s connection directly into the laptop?
No, I do not know why it would be fast in some cases and slow in others,
but internet connection sharing could have any number of interesting
things happening there (which OS, and routing software, and performance is
there?) and the nature of the duplicate ACKs and out-of-order packets is
often caused by weird routers/switches, which is exactly what your shared
connection is doing. Hopefully this is an easy test, along with trying
the other server, though my own testing would seem to make that an invalid
test.
Summary: The LAN trace shows something amiss on the network causing
packets to be sent out of order (not necessarily bad, TCP is designed to
handle it) or acknowledged multiple times (shouldn’t happen in an ideal
network, but can due to odd timing issues, router buffers, etc.). Nothing
about this makes me suspect your client (laptop/wget), so I would try
testing by eliminating other factors, like connection sharing, the router,
even the connection entirely by going to a
library/university/friend’s-house, etc.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
