Какой 16 портовый свитч купить?
а куда/для чего нужен?
compex модель не помню, но внешне выглядит как ps2208b только 16ти портовый. можешь купить другой, но остальные прокляты.
На работу поставить надо.
У меня compex на работе стоит. Да, довольно не плохой. Но зашел счас на ultracomp.ru там свичи с кэшем по 2 Мбит - это хорошо или как? Что дает кэш на свиче?
если это твоя должность - compex, если не твоя, то surecom или что-нибудь более кальное если найдешь, чтобы больше на тебя чужие обязаности не перекладывали 
> Что дает кэш на свиче?
это буффффффер, когда через свитч пытаются пропихнуть больше чем он может, он кладет в буфер, если буффер заполняется, он говорит "занят, отъебитесь" чем больше буфер, тем реже свитч хамит
это буффффффер, когда через свитч пытаются пропихнуть больше чем он может, он кладет в буфер, если буффер заполняется, он говорит "занят, отъебитесь" чем больше буфер, тем реже свитч хамит
Это моя обязанность. Работаю я в гамерском клубе. Просто вот думаю. Если купить свитч с буфером, то лагов по идее должно стать меньше. Кстати, что думаешь насчет свичей D-Link?
> Если купить свитч с буфером, то лагов по идее должно стать меньше.
если ты про cstrike, поставь hlbuster и не парься, cs лагает не из-за сетки. как я понял сейсчас уже есть какой-то свитч? на нем должна быть лампочка типа overrun или что-то похожее, проследи ее состояние, но в целом свитч с умеренным буффером лучше чем с маленьким.
> Кстати, что думаешь насчет свичей D-Link?
хз, я их видел только на картинке, если внутри все тот же реалтек - цена завышена.
если ты про cstrike, поставь hlbuster и не парься, cs лагает не из-за сетки. как я понял сейсчас уже есть какой-то свитч? на нем должна быть лампочка типа overrun или что-то похожее, проследи ее состояние, но в целом свитч с умеренным буффером лучше чем с маленьким.
> Кстати, что думаешь насчет свичей D-Link?
хз, я их видел только на картинке, если внутри все тот же реалтек - цена завышена.
надеюсь, никакой тайны не открою...
мсушная сетка потихоньку на d-link'и переходит, 16ти, 8ти и 5типортовые
качественные имхо свитчи
мсушная сетка потихоньку на d-link'и переходит, 16ти, 8ти и 5типортовые
качественные имхо свитчи
> качественные имхо свитчи
при стоимости подключения 50$ я бы ниже чем 3com вообще не покупал, вот это действительно качественные железки.
при стоимости подключения 50$ я бы ниже чем 3com вообще не покупал, вот это действительно качественные железки.
мы подумаем над этим...
> мы подумаем над этим...
вань, не парься. просто признай, что тебе нравится твоя песочница, мне - моя, больше тут думать не над чем, и если уж по-настоящему мериться х.ями,
то рекомендую следить за динамикой отношения msu/hackers месяц назад (48.45/51.55) и сейчас (46.90/53.10).
вань, не парься. просто признай, что тебе нравится твоя песочница, мне - моя, больше тут думать не над чем, и если уж по-настоящему мериться х.ями,
то рекомендую следить за динамикой отношения msu/hackers месяц назад (48.45/51.55) и сейчас (46.90/53.10).
я только говорил о том, что люблю, когда все сделано на совесть. если эти свитчи лучше, то я обращу на этот тред внимание тех людей, от которых зависят закупки свитчей. все ради качества. и всего. никаких обсуждений хуже/лучше я и не собирался вести...
а 3com хороши взаправду или просто бредновый товар?
а 3com хороши взаправду или просто бредновый товар?
> а 3com хороши взаправду или просто бредновый товар?
взаправду, я сравнивал 8-ми портовый хаб 3com officeconnect и 8-ми портовые eline/trendnet, хаб продуктивнее (скорость с 4мб поднялась до 5мб)
взаправду, я сравнивал 8-ми портовый хаб 3com officeconnect и 8-ми портовые eline/trendnet, хаб продуктивнее (скорость с 4мб поднялась до 5мб)
хотя это могло быть от того, что он хаб .....
> скорость с 4мб поднялась до 5мб
пиздец
маза, дело в руках
меньше 10мбайт/сек по TCP на незагруженной сети не может быть никак
и вообще, коммутаторы таким образом тестировать не имеет смысла, они все покажут одинаковые результаты
пиздец
маза, дело в руках
меньше 10мбайт/сек по TCP на незагруженной сети не может быть никак
и вообще, коммутаторы таким образом тестировать не имеет смысла, они все покажут одинаковые результаты
> маза, дело в руках
> меньше 10мбайт/сек по TCP
1. мы говорим о разных скоростях
2. дело еще в не особо быстром винте, который использовался, в то время на моей машине
> на незагруженной сети
> и вообще, коммутаторы таким образом
если есть желание, уточни что ты имеешь ввиду под "таким образом"
> тестировать не имеет смысла, они все покажут
> одинаковые результаты
почему? я видел другое.
> меньше 10мбайт/сек по TCP
1. мы говорим о разных скоростях
2. дело еще в не особо быстром винте, который использовался, в то время на моей машине
> на незагруженной сети
> и вообще, коммутаторы таким образом
если есть желание, уточни что ты имеешь ввиду под "таким образом"
> тестировать не имеет смысла, они все покажут
> одинаковые результаты
почему? я видел другое.
> 1. мы говорим о разных скоростях
тогда это не имеет отношения к производительности свитча/хаба
она по определению раза в 2 выше приведённых цифр
> на незагруженной сети
в смысле, если по проводам, по которым гонялся тестовый трафик, в это время ещё что-то передавалось, то эксперимент точно некорректный
> если есть желание, уточни что ты имеешь ввиду под "таким образом"
таким образом - значит, измерение скорости передачи между двумя компьютерами
имеет смысл измерять: совокупную пропускную способность, для чего нужно подсоединить компьютер к каждому порту;
задержки коммутации в присутствии нагрузки на других портах;
производительность в пакетах/сек (для чего нужны генераторы мелких пакетов);
производительность "slow path": broadcast, multicast, unknown, скорость обновления forwarding table, всё это в присутствии фоновой нагрузки;
что-то ещё, если у свитча есть дополнительные фичи (например, trunking, QoS).
> почему? я видел другое
как мы выяснили, ты измеряешь не производительность устройства, а что-то ещё
наверное, дело в этом
тогда это не имеет отношения к производительности свитча/хаба
она по определению раза в 2 выше приведённых цифр
> на незагруженной сети
в смысле, если по проводам, по которым гонялся тестовый трафик, в это время ещё что-то передавалось, то эксперимент точно некорректный
> если есть желание, уточни что ты имеешь ввиду под "таким образом"
таким образом - значит, измерение скорости передачи между двумя компьютерами
имеет смысл измерять: совокупную пропускную способность, для чего нужно подсоединить компьютер к каждому порту;
задержки коммутации в присутствии нагрузки на других портах;
производительность в пакетах/сек (для чего нужны генераторы мелких пакетов);
производительность "slow path": broadcast, multicast, unknown, скорость обновления forwarding table, всё это в присутствии фоновой нагрузки;
что-то ещё, если у свитча есть дополнительные фичи (например, trunking, QoS).
> почему? я видел другое
как мы выяснили, ты измеряешь не производительность устройства, а что-то ещё
наверное, дело в этом
пиздецМожет. Такой стек TCP в винде. Во всякому случае в 2000 и все что ниже.
маза, дело в руках
меньше 10мбайт/сек по TCP на незагруженной сети не может быть никак
и вообще, коммутаторы таким образом тестировать не имеет смысла, они все покажут одинаковые результаты
Не надо опять начинать, хорошо? Мы ведь выяснили, что у тебя нет доказательств этого, по крайней мере про 2000 и XP.
Доказательство в том, что 2 машины на одном свитче дают 5 Мб/с. А вот причины этого я уже обломался найти.
> как мы выяснили, ты измеряешь не
> производительность устройства, а что-то ещё
> наверное, дело в этом
да, ты прав, я имел ввиду тест из серии "сколько у меня будет качаться фильм с \\xxx", было что-то типа этого:
S - статичные свитчи, X - тот который менял, W - вне, PC1 - качал с PC2.
ps: насчет комплексного теста описаного тобой - по low-end железу такие данные существуют?
> производительность устройства, а что-то ещё
> наверное, дело в этом
да, ты прав, я имел ввиду тест из серии "сколько у меня будет качаться фильм с \\xxx", было что-то типа этого:
W -- PC2
|
|
S -----\|/----- S
X
S -----/ \----- S -- PC1
S - статичные свитчи, X - тот который менял, W - вне, PC1 - качал с PC2.
ps: насчет комплексного теста описаного тобой - по low-end железу такие данные существуют?
> по low-end железу такие данные существуют?
я не видел, наверное никому не надо, учитывая затраты на тестирование
да и по hi-end не вот-то найдёшь
хотя в принципе любой человек, у которого в подчинении что-то вроде компьютерного класса, может такое делать
я не видел, наверное никому не надо, учитывая затраты на тестирование
да и по hi-end не вот-то найдёшь
хотя в принципе любой человек, у которого в подчинении что-то вроде компьютерного класса, может такое делать
Ну вот смотри доказательства. Делаем smbclinet ///movies, залогиниваемся и отлогиниваемся. Винда конечно wscale поддерживает, только объявляет его равным 0.
14:21:12.508051 10.0.1.1.2969 > 10.0.1.111.139: S [tcp sum ok] 3690485337:3690485337(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 177714695 0> (DF) (ttl 64, id 4089, len 60)
14:21:12.508386 10.0.1.111.139 > 10.0.1.1.2969: S [tcp sum ok] 2886721083:2886721083(0) ack 3690485338 win 64240 <mss 1460,nop,wscale 0> (DF) (ttl 128, id 59915, len 48)
14:21:12.508455 10.0.1.1.2969 > 10.0.1.111.139: . [tcp sum ok] ack 1 win 65535 (DF) (ttl 64, id 45530, len 40)
14:21:12.758486 10.0.1.1.2969 > 10.0.1.111.139: P 1:73(72) ack 1 win 65535 NBT Packet (DF) [tos 0x10] (ttl 64, id 58811, len 112)
14:21:12.758745 10.0.1.111.139 > 10.0.1.1.2969: P [tcp sum ok] 1:5(4) ack 73 win 64168 NBT Packet (DF) (ttl 128, id 59916, len 44)
14:21:12.758781 10.0.1.1.2969 > 10.0.1.111.139: . [tcp sum ok] ack 5 win 65535 (DF) [tos 0x10] (ttl 64, id 2266, len 40)
14:21:12.758864 10.0.1.1.2969 > 10.0.1.111.139: P 73:241(168) ack 5 win 65535 NBT Packet (DF) [tos 0x10] (ttl 64, id 63188, len 208)
14:21:12.759544 10.0.1.111.139 > 10.0.1.1.2969: P 5:104(99) ack 241 win 64000 NBT Packet (DF) (ttl 128, id 59917, len 139)
14:21:12.759573 10.0.1.1.2969 > 10.0.1.111.139: . [tcp sum ok] ack 104 win 65535 (DF) [tos 0x10] (ttl 64, id 40693, len 40)
14:21:16.959479 10.0.1.1.2969 > 10.0.1.111.139: P 241:391(150) ack 104 win 65535 NBT Packet (DF) [tos 0x10] (ttl 64, id 1738, len 190)
14:21:16.960665 10.0.1.111.139 > 10.0.1.1.2969: P 104:227(123) ack 391 win 63850 NBT Packet (DF) (ttl 128, id 59924, len 163)
14:21:16.960705 10.0.1.1.2969 > 10.0.1.111.139: . [tcp sum ok] ack 227 win 65474 (DF) [tos 0x10] (ttl 64, id 25262, len 40)
14:21:16.960971 10.0.1.1.2969 > 10.0.1.111.139: P 391:479(88) ack 227 win 65474 NBT Packet (DF) [tos 0x10] (ttl 64, id 24765, len 128)
14:21:16.961718 10.0.1.111.139 > 10.0.1.1.2969: P 227:283(56) ack 479 win 63762 NBT Packet (DF) (ttl 128, id 59925, len 96)
14:21:16.961751 10.0.1.1.2969 > 10.0.1.111.139: . [tcp sum ok] ack 283 win 65418 (DF) [tos 0x10] (ttl 64, id 61148, len 40)
14:21:16.981860 10.0.1.1.2969 > 10.0.1.111.139: P 479:523(44) ack 283 win 65418 NBT Packet (DF) [tos 0x10] (ttl 64, id 44707, len 84)
14:21:16.982332 10.0.1.111.139 > 10.0.1.1.2969: P [tcp sum ok] 283:322(39) ack 523 win 63718 NBT Packet (DF) (ttl 128, id 59926, len 79)
14:21:16.982370 10.0.1.1.2969 > 10.0.1.111.139: . [tcp sum ok] ack 322 win 65379 (DF) [tos 0x10] (ttl 64, id 47564, len 40)
14:21:20.235732 10.0.1.1.2969 > 10.0.1.111.139: F [tcp sum ok] 523:523(0) ack 322 win 65379 (DF) [tos 0x10] (ttl 64, id 41966, len 40)
14:21:20.236234 10.0.1.111.139 > 10.0.1.1.2969: F [tcp sum ok] 322:322(0) ack 524 win 63718 (DF) (ttl 128, id 59971, len 40)
14:21:20.236353 10.0.1.1.2969 > 10.0.1.111.139: . [tcp sum ok] ack 323 win 65378 (DF) [tos 0x10] (ttl 64, id 63455, len 40)
1. возможно, нужен тюнинг, тебе разве отцы не говорили, что у них скорости выше?
2. размер окна сам по себе не ограничивает пропускную способность, только вместе с задержками в канале
3. SMB не пригоден для измерения пропускной способности сети
2. размер окна сам по себе не ограничивает пропускную способность, только вместе с задержками в канале
3. SMB не пригоден для измерения пропускной способности сети
1. возможно, нужен тюнинг, тебе разве отцы не говорили, что у них скорости выше?
Возможно.
2. размер окна сам по себе не ограничивает пропускную способность, только вместе с задержками в канале
Лень искать ссылку, где показывается что при ненулевой задержке окно в 2^16 байт имеет ограничение в ~ 5.5 Мб/с. И задержка берется не только из канала. Обсчет IP header cksum, TCP cksum и тп.
3. SMB не пригоден для измерения пропускной способности сети
В пределах 100 Mbit пригоден. Ведь с самбы на самбу получается 10 Мб/с.
> Лень искать ссылку
А ты поищи. Наверняка ты что-то не так понял там По крайней мере, я в логах FTP неоднократно наблюдал бОльшие скорости скачивания явно виндовыми клиентами.
> Ведь с самбы на самбу получается 10 Мб/с.
У тебя получается? А что же ты молчал, когда это обсуждали?
А ты поищи. Наверняка ты что-то не так понял там
По крайней мере, я в логах FTP неоднократно наблюдал бОльшие скорости скачивания явно виндовыми клиентами.> Ведь с самбы на самбу получается 10 Мб/с.
У тебя получается? А что же ты молчал, когда это обсуждали?
Я провел некоторые вычисления. Если считать что соединение полнодуплексный 100 Mbit и окно 65535, что протокол overhead 58 байт (18 ether, 20 IP, 20 TCP то окно исчерпает себя при RTT 5.45 мс. Реальный ping -s 1400 через 1 свитч это 1 мс. Получается что окна должно хватать.
Но я не учел две вещи:
1) Машина высылает ack не так быстро как icmp reply, потому что как минимум нужно обсчитать TCP cksum.
2) SMB overhead и NetBIOS overhead. Все таки порт 139 виндов это SMB over NetBIOS.
Но я не учел две вещи:
1) Машина высылает ack не так быстро как icmp reply, потому что как минимум нужно обсчитать TCP cksum.
2) SMB overhead и NetBIOS overhead. Все таки порт 139 виндов это SMB over NetBIOS.
> 2 машины на одном свитче дают 5 Мб/с.
win2k3 - win2k3 в обе стороны 6мб/с, когда было win2k - win2k было тоже самое, мне все же кажется что процесс тормозится винтом, проверить можно сделав два рамдрайва.
win2k3 - win2k3 в обе стороны 6мб/с, когда было win2k - win2k было тоже самое, мне все же кажется что процесс тормозится винтом, проверить можно сделав два рамдрайва.
Доказательство в том, что 2 машины на одном свитче дают 5 Мб/с. А вот причины этого я уже обломался найти.
Глеб, ты неправ
собственными глазами смотрел:
две машины, сетевухи интел и триком,
между ними три свитча.
скорость 7-8 мегов. в реальной сети: в нашей
между и doctor (но это было почти год назад)
ты реально объясни ситауцию.
Может быть стоить купить понавороченнее свитч. Например который поддерживает IEEE802.3ad (Port Trunking). Ну это когда 2 (или более портов) физических порта работают как 1 логический. Это раельно надо тогда, когда гигабитный свитч (или порт) покупать не имеет смысла (по финансовым и пр. соображениям а пропускной способности не хватает для многих пользователей. Вот например реальная ситуация - утром все пришли на работу (у пользователей профили перемещаемые в 2к) и все загружают свой комп. С сервера сразу начинают тянуть (или сравнивать текущий локальный профиль с тем который хратиться на серевре)свой профиль. Сервак просто надрывается (винты крутяться) и сетка тоже. Это имеетс смысл, только если здесь винт не узкое место (например райд массив стоит какой нить шустрый).
Может быть стоить купить понавороченнее свитч. Например который поддерживает IEEE802.3ad (Port Trunking). Ну это когда 2 (или более портов) физических порта работают как 1 логический. Это раельно надо тогда, когда гигабитный свитч (или порт) покупать не имеет смысла (по финансовым и пр. соображениям а пропускной способности не хватает для многих пользователей. Вот например реальная ситуация - утром все пришли на работу (у пользователей профили перемещаемые в 2к) и все загружают свой комп. С сервера сразу начинают тянуть (или сравнивать текущий локальный профиль с тем который хратиться на серевре)свой профиль. Сервак просто надрывается (винты крутяться) и сетка тоже. Это имеетс смысл, только если здесь винт не узкое место (например райд массив стоит какой нить шустрый).
Да нет, нужен обычный свитч, желательно с uplink, конечно, меня просто интересует, какие свичи реже глючат/ лучше работают.
насчет глючности: у свичей это выявить не просто. Одно дело когда у тебя пинги проходят - вообщем по внешним признакам все пашет и работает, но бывают в разных сетевых (кторые используют сеть - например 1С Бухгалтерия сетевая) вылезают глюки. Тут не знаешь на что думать - может прога корявая, может комп глючит и т.д.. Еще при выборе свича обрати внимание на размер буфера и на размер таблицы адресов. Это тоже не маловажный фактор.Посоветуйте плз. или поделитесь соображениями, как выбирать.
Ну дык что ты выбрал - поделись сообществу ....
> 1) Машина высылает ack не так быстро как icmp reply, потому что как минимум нужно обсчитать TCP cksum.
Это фигня, минимум на 2 порядка меньше, чем задержка в канале.
> 2) SMB overhead и NetBIOS overhead. Все таки порт 139 виндов это SMB over NetBIOS.
А вот это не фигня. И, если я правильно понимаю, не из-за оверхеда, а из-за циклов "запрос-ответ", т.е. минимум один RTT на каждый блок передаваемого файла. Если эти блоки меньше или сравнимы с размером TCP-окна, то увеличивать последнее смысла нет.
Это фигня, минимум на 2 порядка меньше, чем задержка в канале.
> 2) SMB overhead и NetBIOS overhead. Все таки порт 139 виндов это SMB over NetBIOS.
А вот это не фигня. И, если я правильно понимаю, не из-за оверхеда, а из-за циклов "запрос-ответ", т.е. минимум один RTT на каждый блок передаваемого файла. Если эти блоки меньше или сравнимы с размером TCP-окна, то увеличивать последнее смысла нет.
Я на работе каждый день вижу скорости типа 6, 7, 8 и даже 9Mb/s между разными компами: Win2k PRO/AS / Linux kernel 2.4.20 samba 2.2.8a; сетевухи: в основном Realtek 8139, пару fxp, DEC, несколько compex; switch-и:2 elnet и infonet (не помню как точно называется) - далеко не бренд. Ничего специально не настраивал ни в железе ни в ОС.
Твои объяснения этого феномена?
Твои объяснения этого феномена?
карма у глебиуса плохая, виндовые боги ему не помогают
Купил compex 2216 - ничего другого в тот день на Савелове не нашел.
То, что ты наблюдаешь это не феномен.
Феномен вот: качаю с w2k по SMB - 5 Мб/с. Начинаю парраллельно качать еще по одной SMB сессии - суммарно 8 Мб/с. Потерь пакетов нет. RTT намного меньше 5 мс.
Феномен вот: качаю с w2k по SMB - 5 Мб/с. Начинаю парраллельно качать еще по одной SMB сессии - суммарно 8 Мб/с. Потерь пакетов нет. RTT намного меньше 5 мс.
Оставить комментарий
olga-grabskaja
Посоветуйте плз. или поделитесь соображениями, как выбирать.