One thing I noticed using netstat is that out of 9 stream only 2
(sometimes 3) have a number different from 0 in the Send-Q column which
I assume means the stream is active. The "active" stream is not always
the same it can change during the transfer which can be observed with
continuous refresh (I set every 2s). The frst thing I thought when I
saw that was having 9 streams was useless since they are not used in
parallel however before mentioning this I was trying to find
confirmation that send-Q different from 0 means active stream.
cheers
alessandra
On 18/02/2013 15:53, Andrew Sansum wrote:
> If the second and subsequent streams are not getting their window open beyond 4K then that tends to suggest packet loss on those streams. It might be worth looking at the tcp segment retransmit rate for single stream versus 9 streams (assuming you can isolate the test sufficiently to measure the difference). Alternatively maybe some smart wireshark/tcpdump magic to spot the retransmitit packets on the higher ports. At least this will give some confirmation of packet loss.
>
> Andrew
>
>> -----Original Message-----
>> From: GRIDPP2: Deployment and support of SRM and local storage
>> management [mailto:[log in to unmask]] On Behalf Of
>> Ewan MacMahon
>> Sent: 18 February 2013 15:47
>> To: [log in to unmask]
>> Subject: Re: sonar tests to BNL
>>
>>> -----Original Message-----
>>> From: Alessandra Forti [mailto:[log in to unmask]]
>>> Sent: 18 February 2013 15:24
>>> To: Ewan MacMahon
>>>> Do we know what ports/port ranges are being used for the gridftp
>>>> connections?
>>> Yes, I wondered that too, infact it's the first thing I thought. We
>>> haven't changed it during the upgrade and we have the paleolitic
>>> 20000-25000
>>>
>> That seems to be what we have too; it's set in the dpm-gsiftp init script -
>> there's a commented out mention of it (with the same values) in
>> /etc/sysconfig/dpm too,
>>
>>> but the default seem to be 50000-51000.
>>>
>> Where are you seeing that?
>>
>>> I scanned one of the
>>> BNL data servers with nmap using those ranges and didn't report
>>> anything filtered.
>>>
>> It could still be an FZK style problem - i.e. they're doing a special firewall
>> bypass for some traffic, but putting the rest through a slower system. If that
>> slower path were still letting stuff through you wouldn't see it in an nmap
>> result.
>>
>>> I'm not sure how else to test this.
>>>
>> A tcptraceroute targeting ports in different ranges might show a difference,
>> but it equally well might not; a lot of firewalls are pretty transparent.
>>
>> Or we ask the BNL folks if they're doing any clever firewall stuff with a bypass
>> for gridftp.
>>
>> Ewan
--
Facts aren't facts if they come from the wrong people. (Paul Krugman)
|