[telephonist]

Схема включения:

клиенты - шейпер - нат - интернет

 

клиент linux, ограничение полосы 100Mбит. Тянем файл в ОДИН поток по HTTP используя wget. Например:

wget http://some.domain.com/test.avi

Скорость около 10MB/s, т.е. где-то около наших 100Мбит.

 

клиент windows 2003, ограничение полосы 100Мбит, точно такие же настройки, как для клиента линукс. Тянем файл в ОДИН поток по HTTP используя wget. Например:

wget http://some.domain.com/test.avi

Скорость около 4MB/s, т.е. где-то около 30-35Мбит. Хотя должно быть 100Mbit. Если сделать несколько паралельных закачек - все в порядке, сумарная скорость будет 100Мбит. А вот один поток именно для WIndows почему-то не превышает 35Мбит.

 

В случае отключения шейпера вообще ситуация не меняется. Максимум 35Мбит для Windows. Linux же без проблем берет все доступную полосу даже для одного потока.

 

То же самое с Winows 7, Windows XP.

[GFORGX]

Может, попробовать свежеустановленную венду с той же сетевой картой, которая у Линукса?

[s.lobanov]

Сделайте 2 дампа ваершарком, сравните размер пакетов, tcp-окна, есть ли ретрансмисии

[Дегтярев Илья]

А пинг с машины до сервера случайно не порядка 14 мс ?

[telephonist]

А пинг с машины до сервера случайно не порядка 14 мс ?

Пинг 12 мс, но это нормальный пинг. А как может быть связана скорость загрузки и пинг? Пинг, уточняю, стабильный, потерь нет.

[telephonist]

Снял дамп вайршарком. Пока только с win2003 - на линукс нужно ставить и разбираться как работает...

 

В дампе с винды постоянно фигурируют сообщения типа

 

 

10 0.002310 195.93.172.131 10.10.0.194 HTTP Continuation or non-HTTP traffic ( это я так понимаю нормально )

 

и

 

15 0.002862 10.10.0.194 195.93.172.131 TCP vrts-ipcserver > http-alt [ACK] Seq=1 Ack=16061 Win=65535 Len=0

 

Вот подробнее

 

 

No. Time Source Destination Protocol Info

15 0.002862 10.10.0.194 195.93.172.131 TCP vrts-ipcserver > http-alt [ACK] Seq=1 Ack=16061 Win=65535 Len=0

 

Frame 15: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)

Arrival Time: Dec 20, 2010 09:44:08.747386000 FLE Standard Time

Epoch Time: 1292831048.747386000 seconds

[Time delta from previous captured frame: 0.000013000 seconds]

[Time delta from previous displayed frame: 0.000013000 seconds]

[Time since reference or first frame: 0.002862000 seconds]

Frame Number: 15

Frame Length: 54 bytes (432 bits)

Capture Length: 54 bytes (432 bits)

[Frame is marked: False]

[Frame is ignored: False]

[Protocols in frame: eth:ip:tcp]

[Coloring Rule Name: Checksum Errors]

[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || mstp.checksum_bad==1]

Ethernet II, Src: AsustekC_5e:64:c2 (00:17:31:5e:64:c2), Dst: AcctonTe_c6:31:70 (00:12:cf:c6:31:70)

Destination: AcctonTe_c6:31:70 (00:12:cf:c6:31:70)

Address: AcctonTe_c6:31:70 (00:12:cf:c6:31:70)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

Source: AsustekC_5e:64:c2 (00:17:31:5e:64:c2)

Address: AsustekC_5e:64:c2 (00:17:31:5e:64:c2)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

Type: IP (0x0800)

Internet Protocol, Src: 10.10.0.194 (10.10.0.194), Dst: 195.93.172.131 (195.93.172.131)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 40

Identification: 0x48a7 (18599)

Flags: 0x02 (Don't Fragment)

0... .... = Reserved bit: Not set

.1.. .... = Don't fragment: Set

..0. .... = More fragments: Not set

Fragment offset: 0

Time to live: 128

Protocol: TCP (6)

Header checksum: 0x0000 [incorrect, should be 0x377c]

[Good: False]

[bad: True]

[Expert Info (Error/Checksum): Bad checksum]

[Message: Bad checksum]

[severity level: Error]

[Group: Checksum]

Source: 10.10.0.194 (10.10.0.194)

Destination: 195.93.172.131 (195.93.172.131)

Transmission Control Protocol, Src Port: vrts-ipcserver (1317), Dst Port: http-alt (8080), Seq: 1, Ack: 16061, Len: 0

Source port: vrts-ipcserver (1317)

Destination port: http-alt (8080)

[stream index: 0]

Sequence number: 1 (relative sequence number)

Acknowledgement number: 16061 (relative ack number)

Header length: 20 bytes

Flags: 0x10 (ACK)

000. .... .... = Reserved: Not set

...0 .... .... = Nonce: Not set

.... 0... .... = Congestion Window Reduced (CWR): Not set

.... .0.. .... = ECN-Echo: Not set

.... ..0. .... = Urgent: Not set

.... ...1 .... = Acknowledgement: Set

.... .... 0... = Push: Not set

.... .... .0.. = Reset: Not set

.... .... ..0. = Syn: Not set

.... .... ...0 = Fin: Not set

Window size: 65535

Checksum: 0x7ac7 [validation disabled]

[Good Checksum: False]

[bad Checksum: False]

[sEQ/ACK analysis]

[This is an ACK to the segment in frame: 14]

[The RTT to ACK the segment was: 0.000013000 seconds]

Edited December 20, 2010 by telephonist

[telephonist]

На всякий случай вот нормальный (я думаю что он нормальный ) пакет

 

 

No. Time Source Destination Protocol Info

14 0.002849 195.93.172.131 10.10.0.194 HTTP Continuation or non-HTTP traffic

 

Frame 14: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)

Arrival Time: Dec 20, 2010 09:44:08.747373000 FLE Standard Time

Epoch Time: 1292831048.747373000 seconds

[Time delta from previous captured frame: 0.000005000 seconds]

[Time delta from previous displayed frame: 0.000005000 seconds]

[Time since reference or first frame: 0.002849000 seconds]

Frame Number: 14

Frame Length: 1514 bytes (12112 bits)

Capture Length: 1514 bytes (12112 bits)

[Frame is marked: False]

[Frame is ignored: False]

[Protocols in frame: eth:ip:tcp:http:data]

[Coloring Rule Name: HTTP]

[Coloring Rule String: http || tcp.port == 80]

Ethernet II, Src: Intel_aa:9c:14 (00:04:23:aa:9c:14), Dst: AsustekC_5e:64:c2 (00:17:31:5e:64:c2)

Destination: AsustekC_5e:64:c2 (00:17:31:5e:64:c2)

Address: AsustekC_5e:64:c2 (00:17:31:5e:64:c2)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

Source: Intel_aa:9c:14 (00:04:23:aa:9c:14)

Address: Intel_aa:9c:14 (00:04:23:aa:9c:14)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

Type: IP (0x0800)

Internet Protocol, Src: 195.93.172.131 (195.93.172.131), Dst: 10.10.0.194 (10.10.0.194)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 1500

Identification: 0x8b8c (35724)

Flags: 0x02 (Don't Fragment)

0... .... = Reserved bit: Not set

.1.. .... = Don't fragment: Set

..0. .... = More fragments: Not set

Fragment offset: 0

Time to live: 123

Protocol: TCP (6)

Header checksum: 0xf3e2 [correct]

[Good: True]

[bad: False]

Source: 195.93.172.131 (195.93.172.131)

Destination: 10.10.0.194 (10.10.0.194)

Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: vrts-ipcserver (1317), Seq: 14601, Ack: 1, Len: 1460

Source port: http-alt (8080)

Destination port: vrts-ipcserver (1317)

[stream index: 0]

Sequence number: 14601 (relative sequence number)

[Next sequence number: 16061 (relative sequence number)]

Acknowledgement number: 1 (relative ack number)

Header length: 20 bytes

Flags: 0x10 (ACK)

000. .... .... = Reserved: Not set

...0 .... .... = Nonce: Not set

.... 0... .... = Congestion Window Reduced (CWR): Not set

.... .0.. .... = ECN-Echo: Not set

.... ..0. .... = Urgent: Not set

.... ...1 .... = Acknowledgement: Set

.... .... 0... = Push: Not set

.... .... .0.. = Reset: Not set

.... .... ..0. = Syn: Not set

.... .... ...0 = Fin: Not set

Window size: 65535

Checksum: 0x322c [validation disabled]

[Good Checksum: False]

[bad Checksum: False]

[sEQ/ACK analysis]

[Number of bytes in flight: 7300]

Hypertext Transfer Protocol

Data (1460 bytes)

 

0000 1e 01 fa af 83 b6 fa d2 53 ff 06 12 95 42 e1 2c ........S....B.,

0010 4b dc 85 c2 5d 54 a5 bd 1d 34 80 98 0a 6c 18 e8 K...]T...4...l..

0020 10 50 56 b2 d6 33 12 77 0e ff 96 ec 86 e1 7d f8 .PV..3.w......}.

................................................................................

......................

0580 da bf 22 33 46 c6 64 5f 31 07 51 06 00 e3 d8 0d .."3F.d_1.Q.....

0590 bb 78 75 a9 37 39 c4 6b a2 26 e5 68 0d ac bc ec .xu.79.k.&.h....

05a0 e1 1b 53 25 92 4e d4 11 75 ba 8d 7e 70 8b 90 38 ..S%.N..u..~p..8

05b0 46 49 57 0a FIW.

Data: 1e01faaf83b6fad253ff06129542e12c4bdc85c25d54a5bd...

[Length: 1460]

Edited December 20, 2010 by telephonist

[Ivan_83]

А вы уверены что у вас вгет одинакого себя ведёт под виндой и не виндой?

Технология доступа случаем не пппое?

мту под виндой и линухом удостоверьтесь что одинаково.

 

На всякий случай отключите все аппаратные фичи в настройках сетевухи под виндой, и поиграйте со значением флов контроля (вкл/выкл).

 

PS: хр = 2003 != виста = семёрка

у них по парно одинаковые стёки, но у семёрки/висты утилизация канала сильно выше при использовании сети стандартными средствами.

Там где ХР даёт 60-70% нагрузки на 100 мегабит канал при копировании файла на шару, семёрка запросто от 90 до 99%.

При том, что тюнинги стёка ХР не помогают менять ситуацию, а семёрку и тюнить не нужно.

[telephonist]

Ситуация немного уточняется, хотя и не проясняется.

 

В данной схеме клиенты - шейпер - нат - интернет

 

На нат кладем файл и качаем его с машины(win2003) скорость - примерно 95 Мбит т.е. с данной машины данные с такой скоростью по протоколу HTTP приниматься могут.

 

Однако загрузка файла из сети дает максимум 4.5 МБ/с ( 36 Мбит/с )

 

 

C:\Documents and Settings\garry>wget  http://www.filmy.net.ua:8080/ffc51d8e5be4a
99f24c315b062065fe4/down/4464/Poslednee_izgnanie_dyavola_dvdrip.avi
--2010-12-21 22:50:49--  http://www.filmy.net.ua:8080/ffc51d8e5be4a99f24c315b062
065fe4/down/4464/Poslednee_izgnanie_dyavola_dvdrip.avi
Resolving www.filmy.net.ua... 195.93.172.131
Connecting to www.filmy.net.ua|195.93.172.131|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1468637184 (1.4G) [video/x-msvideo]
Saving to: `Poslednee_izgnanie_dyavola_dvdrip.avi'

5% [>                                      ] 74,798,380  4.46M/s  eta 7m 19s  ^
C
C:\Documents and Settings\garry>

 

 

 

При этом этот же файл тянется с линукса со скоростью около 10 МБ/с

 

 

 wget http://www.filmy.net.ua:8080/ffc51d8e5be4a99f24c315b062065fe4/down/4464/Poslednee_izgnanie_dyavola_dvdrip.avi
--22:35:29--  http://www.filmy.net.ua:8080/ffc51d8e5be4a99f24c315b062065fe4/down/4464/Poslednee_izgnanie_dyavola_dvdrip.avi
           => `Poslednee_izgnanie_dyavola_dvdrip.avi'
Resolving www.filmy.net.ua... 195.93.172.131
Connecting to www.filmy.net.ua|195.93.172.131|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1.468.637.184 (1.4G) [video/x-msvideo]

12% [===============>                                                                                                                       ] 179.616.517    9.36M/s    ETA 02:58

Edited December 21, 2010 by telephonist

[s.lobanov]

Сделайте же уже дамп трафика с линукса. Ваершарк/тспдамп ставятся ничуть не сложнее, чем в винде. В первую очередь интересны размеры пакетов и размер tcp-окна.

[Дегтярев Илья]

Все ведь уже 100 раз описано. Ботайте матчасть.

В винде XP по умолчанию отключено масштабирование окна, как результат в вашем дампе Window size: 65535.

65kбайт/0,012 мс ~ 40 мбит.

[telephonist]

Все ведь уже 100 раз описано. Ботайте матчасть.

В винде XP по умолчанию отключено масштабирование окна, как результат в вашем дампе Window size: 65535.

65kбайт/0,012 мс ~ 40 мбит.

А как лечить?

[dansoftware]

Все ведь уже 100 раз описано. Ботайте матчасть.

В винде XP по умолчанию отключено масштабирование окна, как результат в вашем дампе Window size: 65535.

65kбайт/0,012 мс ~ 40 мбит.

А как лечить?

SG TCP Optimizer

[telephonist]

Действительно помогло! Спасибо!