[Jugernault]

Ну и дальше наверное только oprofile...

а разве много нового после perf top покажет?

Не много - но мало ли... Тут уже похоже метод зачистки пора применять и смотреть везде куда возможно.

[dbask]

sysstat-9.1.1:

mpstat -P ALL 2

Linux 2.6.33.2-zebra (zebra) 04/27/2010 _x86_64_ (8 CPU)

01:02:13 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle

01:02:15 PM all 0.00 0.00 0.06 0.00 0.19 10.91 0.00 0.00 88.84

01:02:15 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

01:02:15 PM 1 0.00 0.00 0.00 0.00 0.00 21.29 0.00 0.00 78.71

01:02:15 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

01:02:15 PM 3 0.00 0.00 0.00 0.00 0.00 24.26 0.00 0.00 75.74

01:02:15 PM 4 0.00 0.00 0.50 0.00 0.00 0.00 0.00 0.00 99.50

01:02:15 PM 5 0.00 0.00 0.00 0.00 0.99 18.32 0.00 0.00 80.69

01:02:15 PM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

01:02:15 PM 7 0.00 0.00 0.00 0.00 0.50 23.27 0.00 0.00 76.24

 

mpstat -I SUM -P ALL 2

01:09:33 PM CPU intr/s

01:09:35 PM all 25443.41

01:09:35 PM 0 26.83

01:09:35 PM 1 6174.63

01:09:35 PM 2 27.32

01:09:35 PM 3 6187.32

01:09:35 PM 4 26.83

01:09:35 PM 5 6140.49

01:09:35 PM 6 27.32

01:09:35 PM 7 6123.41

Насколько я понимаю, то достаточно пристойные показатели.

Сколько в этот момент было трафика и пакетов в секунду?

 

cat /proc/cpuinfo | grep -E "processor|physical id|apicid|core id"

processor : 0	physical id : 0		core id : 0	apicid : 0
processor : 1	physical id : 0		core id : 2	apicid : 2
processor : 2	physical id : 1		core id : 0	apicid : 4
processor : 3	physical id : 1		core id : 2	apicid : 6
processor : 4	physical id : 0		core id : 1	apicid : 1
processor : 5	physical id : 0		core id : 3	apicid : 3
processor : 6	physical id : 1		core id : 1	apicid : 5
processor : 7	physical id : 1		core id : 3	apicid : 7

В вашем случае получается что работают 3 и 4 ядра обеих процессоров.

 

p.s.

cat /usr/src/linux-2.6.33.2 /.config | grep CONFIG_HZ

cat /usr/src/linux-2.6.33.2 /.config | grep CONFIG_PREEMPT

?

 

Ну и дальше наверное только oprofile...

CONFIG_HZ=100

CONFIG_PREEMPT_NONE=y

 

скорость на одном из интерфейсов:

 

5 minute input rate 534189000 bits/sec, 83227 packets/sec

5 minute output rate 411308000 bits/sec, 84504 packets/sec

 

[Dark_Angel]

HZ = 100 ????

 

Кроме того, я считаю, что 24К прерываний на 8 очередей - это много. Я бы поставил бы по 1К на каждую очередь. Они ведь у Вас всеравно Rx-Tx.

Изменено 27 апреля, 2010 пользователем Dark_Angel

[dbask]

x CONFIG_HZ_100:

x

x 100 Hz is a typical choice for servers, SMP and NUMA systems

x with lots of processors that may show reduced performance if

x too many timer interrupts are occurring.

 

с ITR поэкспериментируем, но неудобство в том что из за отсутствия полноценного генератора трафика, дергать сетевухи приходится только рано утром

[Dark_Angel]

Мне кажется, что Вы просто теряете тики ядра, из-за того, что у Вас тик длится больше чем нужно. Я первый раз вижу роутер с HZ=100. Нет, ну меня они тоже когда-то были с 100, когда ядро не позволяло это нормально менять.

[Jugernault]

Мне кажется, что Вы просто теряете тики ядра, из-за того, что у Вас тик длится больше чем нужно. Я первый раз вижу роутер с HZ=100. Нет, ну меня они тоже когда-то были с 100, когда ядро не позволяло это нормально менять.

"Assigning Interrupts to Processor Cores using 82576 controller" - Не, я конечно понимаю что брошюрка старовата, но если честно, то не вижу почему бы ей не доверять в отношении данного параметра.

Каким по Вашему должно быть значение HZ?

[Lynx10]

у меня

CONFIG_HZ_250=y

# CONFIG_HZ_300 is not set

# CONFIG_HZ_1000 is not set

CONFIG_HZ=250

 

а сколько должно быть кто то в курсе ?

[dbask]

после перераспределения smp_affinity в соответствии с /proc/cpuinfo а именно:

 

/bin/echo 4 > /proc/irq/`cat /proc/interrupts | grep 'eth2-TxRx-0' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity

/bin/echo 4 > /proc/irq/`cat /proc/interrupts | grep 'eth2-TxRx-1' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity

/bin/echo 40 > /proc/irq/`cat /proc/interrupts | grep 'eth2-TxRx-2' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity

/bin/echo 40 > /proc/irq/`cat /proc/interrupts | grep 'eth2-TxRx-3' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity

 

/bin/echo 8 > /proc/irq/`cat /proc/interrupts | grep 'eth3-TxRx-0' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity

/bin/echo 8 > /proc/irq/`cat /proc/interrupts | grep 'eth3-TxRx-1' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity

/bin/echo 80 > /proc/irq/`cat /proc/interrupts | grep 'eth3-TxRx-2' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity

/bin/echo 80 > /proc/irq/`cat /proc/interrupts | grep 'eth3-TxRx-3' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity

 

 

perftop:

--------------------------------------------------------------------------------------------------------------------------------------

PerfTop: 4128 irqs/sec kernel:99.2% [1000Hz cycles], (all, 8 CPUs)

--------------------------------------------------------------------------------------------------------------------------------------

 

samples pcnt function DSO

_______ _____ ___________________________ __________________________________________________________________

 

5768.00 14.3% ip_route_input /lib/modules/2.6.33.2-zebra/build/vmlinux

4779.00 11.8% igb_poll /lib/modules/2.6.33.2-zebra/kernel/drivers/net/igb/igb.ko

2690.00 6.7% _raw_spin_lock /lib/modules/2.6.33.2-zebra/build/vmlinux

1806.00 4.5% ip_forward /lib/modules/2.6.33.2-zebra/build/vmlinux

1804.00 4.5% __slab_free /lib/modules/2.6.33.2-zebra/build/vmlinux

1537.00 3.8% skb_release_head_state /lib/modules/2.6.33.2-zebra/build/vmlinux

1476.00 3.7% __alloc_skb /lib/modules/2.6.33.2-zebra/build/vmlinux

1456.00 3.6% igb_xmit_frame_ring_adv /lib/modules/2.6.33.2-zebra/kernel/drivers/net/igb/igb.ko

945.00 2.3% kfree /lib/modules/2.6.33.2-zebra/build/vmlinux

912.00 2.3% eth_type_trans /lib/modules/2.6.33.2-zebra/build/vmlinux

 

 

динамика загрузки цпу:

2010-04-27_21:17 0.0 0.0 40.3 55.2 0.0 0.0 45.8 50.2

2010-04-27_21:18 0.0 0.0 36.4 43.7 0.0 0.0 40.6 36.5

2010-04-27_21:19 0.0 0.0 39.1 50.9 0.0 0.0 36.7 41.7

2010-04-27_21:20 0.0 0.0 37.2 49.3 0.0 0.0 37.6 44.6

2010-04-27_21:21 0.0 0.0 40.5 43.1 0.0 0.0 38.0 42.5

2010-04-27_21:22 0.0 0.0 40.8 48.1 0.0 0.0 34.8 51.3

2010-04-27_21:23 0.0 0.0 63.9 68.5 0.0 0.0 43.6 55.0

2010-04-27_21:24 0.0 0.0 40.8 45.0 0.0 0.0 35.4 35.3

 

 

динамика дропов eth2:

2010-04-27_21:18 rx_queue_0_drops: 5910 rx_queue_1_drops: 1992 rx_queue_2_drops: 0955 rx_queue_3_drops: 0020

2010-04-27_21:19 rx_queue_0_drops: 5910 rx_queue_1_drops: 1992 rx_queue_2_drops: 0955 rx_queue_3_drops: 0020

2010-04-27_21:20 rx_queue_0_drops: 6163 rx_queue_1_drops: 2073 rx_queue_2_drops: 3361 rx_queue_3_drops: 1671

2010-04-27_21:21 rx_queue_0_drops: 7217 rx_queue_1_drops: 2623 rx_queue_2_drops: 3613 rx_queue_3_drops: 1671

2010-04-27_21:22 rx_queue_0_drops: 7217 rx_queue_1_drops: 2623 rx_queue_2_drops: 3613 rx_queue_3_drops: 1671

2010-04-27_21:23 rx_queue_0_drops: 7728 rx_queue_1_drops: 2623 rx_queue_2_drops: 6329 rx_queue_3_drops: 4136

2010-04-27_21:24 rx_queue_0_drops: 7640 rx_queue_1_drops: 2740 rx_queue_2_drops: 8935 rx_queue_3_drops: 5959

 

скорость на одном из физ интерфейсов:

5 minute input rate 654057000 bits/sec, 109452 packets/sec

5 minute output rate 667326000 bits/sec, 126387 packets/sec

 

 

показатели не идеальные, но на порядок лучше вчерашних

 

P.S.

у кого какие мысли на счет того, на сколько полезен параметр для igb: LLIPort=80 (low latency interrupt port) ?

Изменено 27 апреля, 2010 пользователем dbask

[Dark_Angel]

Поставьте HZ=1000. Если бы эксперементировал с частотой выше, мог бы порекомендовать еще что-то, но выше 1000 не ставил. У ребят c FreeBSD обсуждаемой в соседних топиках бывает и 2000, на сколько я видел.

 

А вообще по поводу почему HZ надо ставить как можно больше - есть инфа в Инете. Поищите темы про роутинг 1 Гбита. Там ребята, когда только Гбит появился и у всех жестко в ядрах стояло HZ=100 не могли нормально разобраться, почему же Гбит не пролазит и начинаются дропы.

 

В кратце это происходит так: например ядро должно 100 раз в секунду переключится на выполнение другой задачи. Задачи поступают блоками и в случае с трафиком - это пачка пакетов, например забраных прерываниями. Далее ядро начинает эти пакеты разгребать. Скажем, разгребать пакеты в данной задаче, текущему ядру - 0.005 сек. Это означает, что по завершению задачи, оно еще будет 0.005 сек колупаться в попе, после чего перейдет к другой задаче. В результате Вы получите свои softirq в топе и в тиках, но реально работа делаться не будет.

 

Если же ядру сказать переключаться 1000 раз в секунду, а задачи например на 0.005 сек, то оно эту задачу выполнит за 5 подходов, после чего пакеты будут просто плавно догружаться в новую задачу для ядра и когда оно будет к ней возвращаться - для него будет всегда работа. То есть в данном случае тики будут, но и работа будет делаться.

 

Смысл ставить HZ=100 я особо не вижу вообще никогда. Наверное это имеет смысл только если нужно обрабатывать большие массивы данных, например видео, когда задача есть всегда в достаточном объеме, чтобы загрузить современные ядра. Но вообще, для современных процессоров, с кучей ядер, 100 переключений в секунду - это ерунда. Накладные расходы при таком низком переключении намного выше засчет простоев в выполненой задаче.

 

Это если на пальцах рассказывать.

 

Отрицательный момент для высокого HZ только один: накладные расходы на переключение. Очевидно, чем чаще - тем больше. Вот умные дядьки пишущие ядро для линукса решили, что чаще 1000 раз переключаться не нужно будет никому и никогда и жестко прибили эту настройку. Уроды.

 

А насчет LLIPort я Вам сказал еще в самом начале.

[DemYaN]

CONFIG_NO_HZ=y

но если используется NET_SCHED, желательно CONFIG_HZ_1000=y, т.к. где-то в коде осталась привязка

[Dark_Angel]

А вот NO_HZ - это, мне кажется, плохая идея, т.к. ядро в этом случае будет само выбирать как часто ему переключаться. Че-то я не верю в магию автоматики.

[Умник]

Dark_Angel, я думаю что все далеко не так просто.

 

http://thread.gmane.org/gmane.linux.kernel/831840

 

Там же высказана крамольная мысль следующего характера:

I would think that 60 HZ would be sufficient

Видимо scheduler опирается еще на какой-то таймер, потому что иначе это безумие предлагать 60 HZ.

 

P.S.: В Ubuntu Server Edition HZ=100 (в desktop - 250). Лично я предпочитаю безопасное значение 250. Хотя есть сервера и с 1000. Дропов там не больше и не меньше чем на серверах, где HZ=250.

 

DemYaN, NET_SCHED уже давно сконвертирован в hrtimers.

 

[dbask]

попробую с HZ=250,

 

а что скажете насчет параметра ring buffer tx/rx: ethtool -G 1024 eth(x) (max 4096) ?

 

есть ли подобранное оптимальное значение для гигабит роутинга?

[DemYaN]

А вот NO_HZ - это, мне кажется, плохая идея, т.к. ядро в этом случае будет само выбирать как часто ему переключаться. Че-то я не верю в магию автоматики.

ну если шейпа нет, то фиксированное значение HZ и отказ от hrtimers может будет и лучше... но если шейп то hrtimers и соответственно NO_HZ

 

DemYaN, NET_SCHED уже давно сконвертирован в hrtimers.

оно то кончено да, но помнится были какие-то проблемы еще в 2.6.28....

порылся и нашел:

http://lists.openwall.net/netdev/2009/01/09/63

http://lists.openwall.net/netdev/2009/01/13/14

Изменено 27 апреля, 2010 пользователем DemYaN

[Jugernault]

попробую с HZ=250,

 

а что скажете насчет параметра ring buffer tx/rx: ethtool -G 1024 eth(x) (max 4096) ?

 

есть ли подобранное оптимальное значение для гигабит роутинга?

Насколько я понимаю, то панацеи нет.

Стоит следить за

rx_no_buffer_count: 0

rx_missed_errors: 0

и если начинают сыпаться ошибки, то постепенно увеличивать кольцевой буфер.

[Умник]

DemYaN, там потом выяснилось, что у товарища оказался включен nmi_watchdog, который всегда вырубает hrtimers. В такой ситуации он конечно же зависел от HZ.

[Dark_Angel]

2Умник: прочитал всё обсуждение в присланном Вами линке. Там немного не наш случай. Они говорят о декстопах, говорят о сбережении енергии для idle. Потом проводят дибильные опыты, которые показывают, что HZ=100 и HZ=1000 генерирют разное количество прерываний timers. Божемой какая находка.

 

То что сеть пытаются отвязать от HZ - да, попытки есть, но факт в том, что даже для функций ядра, а я уже не говорю про user-space, HZ влияет. Возможно даже сеть работает на hrtimers, но процессорное время, видимо, выделяется всеравно на основании переключений контекстов ядра.

 

Влияет HZ по-разному. И в линке который Вы дали - только подтверждения моего объяснения. Дали задачу в форе прокрутится циклу, которому крутится 255s при HZ=100 и 264 при HZ=1000. Почему возникла разница - очевидно, я написал об этом. Почему лучше иметь ниже HZ - тоже очевидно. Только вот задача у нас другая. Я бы вообще с удовольствием ставил HZ=количеству решаемых задач на машине, но увы, так работать не будет, как Вы понимаете.

[DemYaN]

nmi_watchdog, который всегда вырубает hrtimers

оу, будем знать, ибо nmi_watchdog используется активно

 

[Умник]

Dark_Angel, но мой опыт показывает, что HZ абсолютно не влияет на производительность forwarding-а и работоспособность NAPI: что 100, что 1000 - не важно.

 

[dbask]

дождались, пошли дропы

2010-04-27_23:06 rx_queue_0_drops: 1339954 rx_queue_1_drops: 421509 rx_queue_2_drops: 7078168 rx_queue_3_drops: 373094

2010-04-27_23:07 rx_queue_0_drops: 1344670 rx_queue_1_drops: 426635 rx_queue_2_drops: 7083337 rx_queue_3_drops: 377748

2010-04-27_23:08 rx_queue_0_drops: 1348199 rx_queue_1_drops: 429243 rx_queue_2_drops: 7086293 rx_queue_3_drops: 382136

2010-04-27_23:09 rx_queue_0_drops: 1355417 rx_queue_1_drops: 434810 rx_queue_2_drops: 7095601 rx_queue_3_drops: 390017

2010-04-27_23:10 rx_queue_0_drops: 1365047 rx_queue_1_drops: 443653 rx_queue_2_drops: 7100754 rx_queue_3_drops: 396763

2010-04-27_23:11 rx_queue_0_drops: 1372977 rx_queue_1_drops: 451244 rx_queue_2_drops: 7109176 rx_queue_3_drops: 405901

2010-04-27_23:12 rx_queue_0_drops: 1380744 rx_queue_1_drops: 459095 rx_queue_2_drops: 7116157 rx_queue_3_drops: 419069

2010-04-27_23:13 rx_queue_0_drops: 1395332 rx_queue_1_drops: 468100 rx_queue_2_drops: 7126253 rx_queue_3_drops: 432735

2010-04-27_23:14 rx_queue_0_drops: 1404538 rx_queue_1_drops: 475213 rx_queue_2_drops: 7129817 rx_queue_3_drops: 437675

2010-04-27_23:15 rx_queue_0_drops: 1410845 rx_queue_1_drops: 480156 rx_queue_2_drops: 7135490 rx_queue_3_drops: 444030

2010-04-27_23:16 rx_queue_0_drops: 1426273 rx_queue_1_drops: 490986 rx_queue_2_drops: 7148307 rx_queue_3_drops: 455064

2010-04-27_23:17 rx_queue_0_drops: 1432640 rx_queue_1_drops: 497733 rx_queue_2_drops: 7155259 rx_queue_3_drops: 460590

 

 

 

скорость:

5 minute input rate 796667000 bits/sec, 134530 packets/sec

5 minute output rate 619538000 bits/sec, 136617 packets/sec

 

ЦПУ:

2010-04-27_23:05 0.0 0.0 92.1 81.3 0.0 0.0 60.6 78.5

2010-04-27_23:06 0.0 0.0 60.7 71.6 0.0 0.0 77.9 78.9

2010-04-27_23:07 0.0 0.0 79.8 88.3 0.0 0.0 96.3 94.8

2010-04-27_23:08 0.0 0.0 96.8 93.6 0.0 0.0 96.0 96.0

2010-04-27_23:09 0.0 0.0 89.9 91.7 0.0 0.0 95.8 93.4

2010-04-27_23:10 0.0 0.0 96.6 91.1 0.0 0.0 95.8 97.0

2010-04-27_23:11 0.0 0.0 94.0 94.0 0.0 0.0 95.8 93.8

2010-04-27_23:12 0.0 0.0 94.8 95.0 0.0 0.0 95.2 91.9

2010-04-27_23:13 0.0 0.0 95.7 89.9 0.0 0.0 89.7 94.8

 

perf top:

--------------------------------------------------------------------------------------------------------------------------------------

PerfTop: 4256 irqs/sec kernel:99.6% [1000Hz cycles], (all, 8 CPUs)

--------------------------------------------------------------------------------------------------------------------------------------

 

samples pcnt function DSO

_______ _____ ___________________________ __________________________________________________________________

 

6081.00 16.4% ip_route_input /lib/modules/2.6.33.2-zebra/build/vmlinux

5393.00 14.5% igb_poll /lib/modules/2.6.33.2-zebra/kernel/drivers/net/igb/igb.ko

2394.00 6.4% _raw_spin_lock /lib/modules/2.6.33.2-zebra/build/vmlinux

2266.00 6.1% ip_forward /lib/modules/2.6.33.2-zebra/build/vmlinux

2235.00 6.0% __slab_free /lib/modules/2.6.33.2-zebra/build/vmlinux

1645.00 4.4% __alloc_skb /lib/modules/2.6.33.2-zebra/build/vmlinux

1618.00 4.4% igb_xmit_frame_ring_adv /lib/modules/2.6.33.2-zebra/kernel/drivers/net/igb/igb.ko

1401.00 3.8% skb_release_head_state /lib/modules/2.6.33.2-zebra/build/vmlinux

1117.00 3.0% eth_type_trans /lib/modules/2.6.33.2-zebra/build/vmlinux

 

 

и что бросается в глаза:

 

mpstat -I SUM -P ALL 2

Linux 2.6.33.2-zebra (zebra) 04/27/2010 _x86_64_ (8 CPU)

 

11:16:36 PM CPU intr/s

11:16:38 PM all 6366.19

11:16:38 PM 0 19.52

11:16:38 PM 1 19.52

11:16:38 PM 2 1093.33

11:16:38 PM 3 1399.52

11:16:38 PM 4 19.52

11:16:38 PM 5 19.52

11:16:38 PM 6 1939.05

11:16:38 PM 7 1141.43

 

11:16:38 PM CPU intr/s

11:16:40 PM all 4817.41 (при незагруженных процах всегда было ~24000)

11:16:40 PM 0 18.41

11:16:40 PM 1 18.41

11:16:40 PM 2 750.25

11:16:40 PM 3 880.60

11:16:40 PM 4 18.91

11:16:40 PM 5 18.91

11:16:40 PM 6 1460.70

11:16:40 PM 7 938.31

^C

 

Итак,

будем уменьшать ITR

 

 

[Умник]

options igb IntMode=2,2,2,2 InterruptThrottleRate=3000,3000,3000,3000 RSS=4,4,4,4 QueuePairs=1,1,1,1 LLIPort=80

Я бы посоветовал вообще убрать IntMode, InterruptThrottleRate, LLIPort и доверится драйверу.

 

Еще RSS=4,4,4,4 превратить в RSS=0,0,0,0 - драйвер сам разберется с количеством очередей.

[Jugernault]

options igb IntMode=2,2,2,2 InterruptThrottleRate=3000,3000,3000,3000 RSS=4,4,4,4 QueuePairs=1,1,1,1 LLIPort=80

При таких опциях ethtool -c eth2 что показывает.

 

 

[Dark_Angel]

2Умник: У меня просто опыт подсказывает как раз обратное, поэтому давайте анализировать. А можете пройтись по паре функций из перфтопа и сказать, что это за функции и почему они там? Нет ли странных?

 

Насчет ITR - я бы ставил статически низкий. Драйвер по умолчанию идет в Dynamic conservative mode и может генерить десятки тысяч перываний. Они в данном случае совсем не нужны, даже учитывая, что они MSI-X.

Изменено 27 апреля, 2010 пользователем Dark_Angel

[Умник]

Драйвер по умолчанию идет в Dynamic mode и может генерить десятки тысяч перываний.

Ну и пусть генерит, если процессор при этом не умирает. Всяко лучше, чем неугомонный ksoftirqd, который в нормальных условиях вообще просыпаться не должен.

А можете пройтись по паре функций из перфтопа и сказать, что это за функции и почему они там? Нет ли странных?

Я не знаю как отличить странные функции от не странных... И как это поможет изучить влияние HZ на forwarding?

 

Судя по этому http://downloadmirror.intel.com/13663/eng/README.txt - dynamic mode не может нагенерить > 20K прерываний в секунду. Что кстати подтверждает мой опыт. Никогда не видел больших значений.

[dbask]

options igb IntMode=2,2,2,2 InterruptThrottleRate=3000,3000,3000,3000 RSS=4,4,4,4 QueuePairs=1,1,1,1 LLIPort=80

При таких опциях ethtool -c eth2 что показывает.

ethtool -c eth2

Coalesce parameters for eth2:

Adaptive RX: off TX: off

stats-block-usecs: 0

sample-interval: 0

pkt-rate-low: 0

pkt-rate-high: 0

 

rx-usecs: 325

rx-frames: 0

rx-usecs-irq: 0

rx-frames-irq: 0

 

tx-usecs: 0

tx-frames: 0

tx-usecs-irq: 0

tx-frames-irq: 0

 

rx-usecs-low: 0

rx-frame-low: 0

tx-usecs-low: 0

tx-frame-low: 0

 

rx-usecs-high: 0

rx-frame-high: 0

tx-usecs-high: 0

tx-frame-high: 0