Перейти к содержанию
    

С какой минимальной суммарной латентностью можно передавать данные по Ethernet?

Есть необходимость максимальной быстро передавать данные из микроконтроллера одной платы крейта в микроконтроллер другой платы этого же крейта.

Прочитал в инете, что существуют микроконтроллеры с встроенным Ethernet PHY интерфейсом, обеспечивающие чуть ли не гигабитную скорость.

Но скорость это хорошо, но какая при этом латентность?

 

А то скорость может большая при больших объёмах данных.

 

А если у меня пакеты по 2 байта (а мне реально нужно 2...32 байта передавать, но очень быстро, за сотню другую наносекунд), то подготовительные операции по транспортировке сожрут всю производительность на таких маленьких пересылках?

Смысл в том, что в двух микроконтроллерах есть база данных 32 байта.

Нужно поддерживать их синхронность.

Любой изменение в одной из БД не позднее пары сотен наносекунд должно быть произведено и в другой копии БД

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

32байта / 100нс = 320МБайт/c = 2.5Гбит/c.

езернет пакеты минимум 64 вроде байта, на 100 мбитах = 5.2мкс. и 0.5мкс для гигабита.

хотя например etherCAT пакеты "налету" разбирает с минимальной (но тоже с ненулевой) задержкой, не дожидаясь всего пакета целиком. но контрольную сумму всё равно в конце поверить надо.

но так как ограничение на длину пакета снизу это, насколько понимаю, тяжёлое наследие царского режима полудуплекса, что для гигабита вроде как вообще не актуально, наверное можно и подсократить.

через всякие свичи/маршрутизаторы я бы такие пакеты пускать не стал (вдруг кто-нибудь дропнет посчитав испорченным), а внутри одного крейта пожалуй можно.

тем более что внутри крейта можно даже пожалуй и без физики прямо R[G]MII по бэкплэйну пустить, и ещё аж несколько байт сэкономить на преамбуле.

хотя она в исходном виде из 8 байт вроде как тоже наследие исключительно 10мбит и нынче и просто байта 0x5D хватать должно.

да и ethernet адресация из 12 байт для точка-точка тоже не особо нужна.

но проблема имхо именно в скорости а не латентности.

и какие там "подготовительные операции"? с одной стороны данные в MAC засунули, они, внезапно, сразу же по мере передачи, у приёмника вылазить начнут. в весь стек сетевых протоколов вплоть до TCP и даже выше, их при этом заворачивать вовсе не обязательно, раз так скорость передачи двух байт важна.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, _pv сказал:

раз так скорость передачи двух байт важна.

Важна скорость синхронизации баз данных в двух платах.

Чтобы любое изменение БД в одном из устройств за доли микросекунды было проведено и в другом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

6 часов назад, DeadCadDance сказал:

Есть необходимость максимальной быстро передавать данные из микроконтроллера одной платы крейта в микроконтроллер другой платы этого же крейта.

Смысл в том, что в двух микроконтроллерах есть база данных 32 байта.

Нужно поддерживать их синхронность.

Любой изменение в одной из БД не позднее пары сотен наносекунд должно быть произведено и в другой копии БД

SPI и LVDS трансиверы

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

27 minutes ago, DeadCadDance said:

Важна скорость синхронизации баз данных в двух платах.

Чтобы любое изменение БД в одном из устройств за доли микросекунды было проведено и в другом.

Для ADIN1300 можно оценить суммарную латентность для передачи и приема 64 байт:

Т = 52 + 64 * 8 + 248 + 64 * 8 =  1324 ns, или 1.324 мкс.

То есть, за доли микросекунды 64 байта (минимальный размер Ethernet кадра) не передать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 минуту назад, blackfin сказал:

То есть, за доли микросекунды 64 байта (минимальный размер Ethernet кадра) не передать.

А если передавать не 64 байта, а реально 2 байта?

Или это логика зашита в микроконтроллере и передавать меньше 64-х байт не получиться?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

8 minutes ago, DeadCadDance said:

А если передавать не 64 байта, а реально 2 байта?

Или это логика зашита в микроконтроллере и передавать меньше 64-х байт не получится?

Эта логика "зашита" в стандарте Ethernet'а.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 минут назад, blackfin сказал:

Эта логика "зашита" в стандарте Ethernet'а.

А микроконтроллер обязательно должен поддерживать стандарт?

Без всяких лайфхаков?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 minute ago, DeadCadDance said:

А микроконтроллер обязательно должен поддерживать стандарт?

Без всяких лайфхаков?

У вас же изначально вопрос поставлен: "С какой минимальной суммарной латентностью можно передавать данные по Ethernet?"

Про "лайфхак" в названии темы ничего не сказано.

Ну и как вы собираетесь передавать/принимать данные в/из PHY на скорости 125 МБ/с минуя MAC и RGMII?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

12 минут назад, blackfin сказал:

У вас же изначально вопрос поставлен: "С какой минимальной суммарной латентностью можно передавать данные по Ethernet?"

Про "лайфхак" в названии темы ничего не сказано.

Ну тут Езернет в смысле не SPI, не CAN, не UART, не I2C

Так как все они медленные, не гигабитные

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

43 минуты назад, DeadCadDance сказал:

Ну тут Езернет в смысле не SPI, не CAN, не UART, не I2C

Так как все они медленные, не гигабитные

Гигабиты в Ethernet это среднее за период.

А вам необходима синхронная передача. Синхронее SPI  я не знаю что придумать.

О, еще же QuadSPI есть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

59 минут назад, HardEgor сказал:

О, еще же QuadSPI есть.

Да ещё если там DDR режим поддерживается... Но таких МК, имхо, немного, надо искать. Ну, и хочется понять 100-200 нс - это бюджет на всё или только на передачу? Потому как если на всё, то идея сомнительная - какой МК умеет за единицы нс отрабатывать прерывания? Там десятки тактов только на активацию прерывания уходят. Синхронизация с такой точностью - это куда-то в аппаратную область надо смотреть, типа ПЛИС.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 hours ago, blackfin said:

Для ADIN1300 можно оценить суммарную латентность для передачи и приема 64 байт:

 Т = 52 + 64 * 8 + 248 + 64 * 8 =  1324 ns, или 1.324 мкс.

 То есть, за доли микросекунды 64 байта (минимальный размер Ethernet кадра) не передать.

64*8 наверное зря два раза посчитано, не?

так как через 68 нс передатчик начнёт передавать, а ещё через 226 приёмник начнёт принимать, посылку длительностью 64*8=512 нс, итого 806нс.

ну и phy там не особо нужен в пределах одного крейта, можно и прямо RGMII по бэкплэйну пустить, проводов там не сильно больше.

а с таким "езернетом" на ограничение длины пакета в 64 байта и наплевать пожалуй можно.

хотя и тупо 16ти битная параллельная шина (или PPI у adsp-bf) на 66МГц за 250нс 32 байта передаст.

ну или поставить этим обоим МК общую асинхронную статическую внешнюю память двухпортовую, с 8-10нс временем цикла,

но опять же, как заметил dxp, мало того, что пока МК поймёт что новые данные прилетели десятки, а то и сотня нс пройдёт, а ведь с данными наверное ещё что-то осмысленное сделать надо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 hours ago, DeadCadDance said:

Любой изменение в одной из БД не позднее пары сотен наносекунд должно быть произведено и в другой копии БД

Такую латентность сможет обеспечить только шина MSEBI в микроконтроллерах Renesas серии RZ/N 
Правда она 32-х разрядная.
Но зато даст 500 Мегабайт в сек без радиатора. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

20 minutes ago, AlexandrY said:

Такую латентность сможет обеспечить только шина MSEBI в микроконтроллерах Renesas серии RZ/N 

Только Renesas, да-да.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...