Когда гигабитные каналы возвращаются к скорости 100 Мбит, обычной причиной является плохая разводка. 10, 100, 1000 и даже 10000 Мбит / с прекрасно сосуществуют на одном и том же коммутаторе (или, возможно, даже быстрее, но более быстрые коммутаторы поддерживают на 10 и 100 Мбит / с все меньше и меньше). Проверьте статистику NIC для ошибок FCS, runts или других отбрасываний.
1000BASE-T требует работы всех четырех витых пар, в то время как 100BASE-TX использует только две из них. Кроме того, 1000BASE-T немного более требователен к кабелю, поскольку линейное кодирование немного сложнее. Многие устройства переключаются на 100BASE-TX при сбое гигабитного согласования. Ссылка также может вообще потерпеть неудачу.
Все остальное, что было здесь описано, - переполнение буфера или управление потоком НЕ оказывает влияния на скорость канала согласования (физический уровень L1) и НИКОГДА не вызывает сбой или откат канала.
Коммутатор всегда получает кадр полностью, прежде чем переслать его (сохранить и переслать) - большинство так или иначе делают, при разных скоростях соединения все коммутаторы используют сохранение и пересылку. Нет проблем получить кадр на один порт 10 Мбит / с и переслать его на другой порт 100 Гбит / с или наоборот.
Управление потоком может мешать эффективной пропускной способности, но никогда не изменяет скорость канала физического уровня .
Когда гигабитный порт пытается отправить поток с полной скоростью на устройство со скоростью 100 (или 10) Мбит / с, и управление потоком активно на всех устройствах, кадры паузы, отправленные с низкоскоростного устройства, будут подавлять гигабитный порт отправителя даже если другой получатель захочет получить полную скорость - это называется блокировкой заголовка и является недостатком проекта.
Устаревшее управление потоком, как правило, не должно использоваться, если вы не понимаете его функции и оно работает в вашем сценарии. Контроль потока намного лучше оставить на транспортном уровне (особенно TCP) или протоколы прикладного уровня.