LINUX.ORG.RU

Пара вопросов по железу...


0

0

Вопрос 1. Материнская плата и жеский диск поддерживают режим UDMA-100. Как узнать в Linux'e (Kernel 2.2.14 - RedHat 6.2) используется ли режим UDMA-100 и используется ли UDMA вообще?

Вопрос 2. Сетевая плата на 10/100 Мбит поддерживает полный дуплекс. Как узнать в Linux'e (Kernel 2.2.14 - RedHat 6.2) на какой скорости работает плата (на 10 или на 100 Мбит) и работает ли она в режиме полного дуплекса или нет?

anonymous

1) man hdparm
2) набери /sbin/ifconfig и посмотри для нужного сетевого интерфейса значение collisions:. Если =0, то работает в full duplex, если !=0, то half (желательно перед этим данный интерфейс не надолго нехило нагрузить). При скорость не знаю.

abramoff
()

Уверен насчет collision и duplex? При сильной нагрузке и при дуплексе хаб может останавливать передачу, если уже не может ее забуферить? Не лучше ли сообщения посмотреть при загрузке модуля?!

speer
()

2speer:
Тут ты неправ. Во первых, если мы говорим про FD, то не хаб, а свич (мост). Во вторых, при работе в FD свич не имеет права устраивать коллизии и нет смысла захватывать среду несколько раньше для регулировки потока, как это делается при HD. Поток при FD регулируется передачей спецсимволов. Вообще-то на свиче обычно есть светодиодики, которые режим показывают. Чего бы туда не глянуть? Не все модули пишут такую диагностику. Например, 8139too пишет, а ne2k-pci - нет.

abramoff
()

>>>Тут ты неправ. Я не говорил что ты ошибаешься, попросил уточнить.

>>>Во первых, если мы говорим про FD, то не хаб, а свич (мост).

C FD терминология расширилась/перепуталась. Пример: у меня есть ХАБ 10/100 fullduplex (Compex, номер не помню, восьмипортовый, stackable). Он не свитч, так как все во все порты транслирует, однако у него есть буферизация пакетов, поскольку (1) имеется таки честный дуплекс, (2) между 10ой и 100ой стоит brige aka switch. Вот и разбери, как его называть.

Коллизии (лампочка на хабе!) происходят просто за милую душу, особливо с Win98 клиентами, хотя сетевые карты очень даже приличные - на Intel41143 (tulip!) дуплекс включен.

>>>Во вторых, при работе в FD свич не имеет права устраивать коллизии

Конечно, если он свич!

>>>Вообще-то на свиче обычно есть светодиодики, которые режим показывают.

Это если цена ему больше $300!

Хотя вопрос остается, что же подразумевается под fd в хабе?!

speer
()

>>>Тут ты неправ.

Я не говорил что ты ошибаешься, попросил уточнить.

>>>Во первых, если мы говорим про FD, то не хаб, а свич (мост).

C FD терминология расширилась/перепуталась. Пример: у меня есть ХАБ 10/100 fullduplex (Compex, номер не помню, восьмипортовый, stackable). Он не свитч, так как все во все порты транслирует, однако у него есть буферизация пакетов, поскольку (1) имеется таки честный дуплекс, (2) между 10ой и 100ой стоит brige aka switch. Вот и разбери, как его называть.

Коллизии (лампочка на хабе!) происходят просто за милую душу, особливо с Win98 клиентами, хотя сетевые карты очень даже приличные - на Intel41143 (tulip!) дуплекс включен.

>>>Во вторых, при работе в FD свич не имеет права устраивать коллизии

Конечно, если он свич!

>>>Вообще-то на свиче обычно есть светодиодики, которые режим показывают.

Это если цена ему больше $300!

Хотя вопрос остается, что же подразумевается под fd в хабе?! Я подозреваю, что пока внутренний буфер не переполнился, они НЕ ДОПУСКАЮТ столкновения пакетов и могут обеспечить двунаправленную передачу на один NIC, а если нет - извини, делают бяку.

speer
()

>Коллизии (лампочка на хабе!) происходят просто за милую душу

Может у тебя он работает не в FD? Почему ты решил, что работает в FD? AFAIK, FD и коллизии не совместимы.

>Хотя вопрос остается, что же подразумевается под fd в хабе?! Я
>подозреваю, что пока внутренний буфер не переполнился, они НЕ
>ДОПУСКАЮТ столкновения пакетов и могут обеспечить двунаправленную
>передачу на один NIC, а если нет - извини, делают бяку.

Да, вопрос интересный. Мне не приходилось близко сталкиваться с подобными устройствами. Я согласен, если в хабе есть буфер, теоретически можно организовать двунаправленную передачу (FD). Но даже если буфер переполняется, хабу не обязательно создавать коллизию, чтобы прекратить передачу. Он может:
1) Просто отбрасывать пакеты (это будут фиксить протоколы верхнего уровня.
2) Послать передающей станции определенный пакет (спецсимвол), чтобы она прекратила передачу (грубо говоря, заткнулась :). При чем передача этого спецсимвола не обязана вызывать коллизию.
AFAIK, именно второй случай и описывает стандарт на устройства, поддерживающие FD. То есть управление потоком осуществляется через спецсимволы и устройства, умеющие FD, должны их понимать.
Я этим хочу сказать, FD - это работа без коллизий, т.е. устройство не имеет права их организовывать.
Кое-что из этого основано на моих измышлениях и может быть неверным. Если кто более в курсе дела, разъясните, пожалуйста.

abramoff
()

2 abramoff:

Большое спасибо за подсказку про hdparm. После тонкой подстройки харда результат превзошел все ожидания.

anonymous
()

>>>Может у тебя он работает не в FD? Почему ты решил, что работает в FD?

Ну так думают и сообщают драйвера сетевых карт, что в Linux, что в NT/2000 ...

>>>AFAIK, FD и коллизии не совместимы.

Я тоже так думал, пока с обратным не столкнулся.

Далее - только догадки на основе наблюдений и рассуждений. Точности наверное надо искать у Беккера на scyld.com, в его мейл-листах и линках...

>>>Но даже если буфер переполняется, хабу не обязательно создавать коллизию, чтобы прекратить передачу. Он может:

>>>1) Просто отбрасывать пакеты (это будут фиксить протоколы верхнего уровня.

Это не должно делаться в приличных хабах, так как переадресует проблему с уровня адаптера (транспортного) на уровень соединения - это накладно и некультурно.

>>>2) Послать передающей станции определенный пакет (спецсимвол), чтобы она прекратила передачу (грубо говоря, заткнулась :).

Так и должно происходить, НО:

-- в начальных стандартах четко написано, что FD только для peer2peer соединений, то есть не для хаба, в жизни это не так.

-- negotiation - процесс договора о взаимодействии между двумя PHY (который сам называется MII), в настоящий момент реализован не менее чем двумя способами, отчего бывают проблемы несовместимости конкретных NIC и хабов/свичей. Видимо это же распространяется на управляющие пакеты. Стандартное решение проблемы - запретить FD, тем более, что не много потеряется...

-- MII реализован аппаратно, драйвер NIC в это не вмешивается и поправить ничего не может.

-- хочет или не хочет ХАБ избегать столкновений, но когда встречаются несколько попыток передачи от РАЗНЫХ узлов, а буфер кончился - делать нечего - пакеты накладываются, искажаются и, как положено, отбрасываются всеми, кто слушает "эфир". Хаб однозначно фиксирует коллизию в этом случае, а вот что делает сетевая карта, которая не участвовала в инциденте? Они, наверное, могут вести себя по разному...

Выводы: (1)Дуплекс в хабах не совсем честно реализован, он появился как побочный эффект от буферения пакетов в двухскоростных устройствах (10/100), эффекта от него в нагруженных сетях никакого, а когда трафик низкий - что с ним, что без него, все равно работает.

(2) Лучше использовать свичи, тем более что разница в цене уже малоощутима для массовых устройств. Я недавно поменял несколько 8port IntelInBusiness Hub на Switch, когда увидел, что разница у поставщика меньше $10!

speer
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.