И иксией

Генератор трафика на базе dpdk.
Но он мутный какой-то.

Фичи заявленные нормальные, но надо еще применить.
Меня заманила возможность шабланизации трафика.

Так шо кошечке пизди, собачке пизди, мне не пизди

В девенул отпровлял?

хуй знает, я кратко гуглил - пишут что там нормальная реализация. условно вот кто-то мерил и получал вот так:

clock_gettime(CLOCK_MONOTONIC_RAW)       100ns/call
clock_gettime(CLOCK_MONOTONIC)           25ns/call
clock_gettime(CLOCK_REALTIME)            25ns/call
clock_gettime(CLOCK_PROCESS_CPUTIME_ID)  400ns/call
rdtsc (implementation @DavidSchwarz)     600ns/call

дпдк го брр

Ну открой ты мануал интела епт

Чо чего дрочит

А не вангуй по говнокоду спизженному из бсд

И запатченному жопой

Узкоглазой

However, yes, most modern platforms will have a suitable clock_gettime call that is implemented purely in user-space using the VDSO mechanism, and will reliably take something like 20 to 30 nanoseconds to complete.

Internally, this is using rdtsc or rdtscp for the fine-grained portion of the time-keeping, plus adjustments to keep this in sync with wall-clock time (depending on the clock you choose) and a multiplication to convert from whatever units rdtsc has on your platform to nanoseconds.

Not all of the clocks offered by clock_gettime will implement this fast method, and it's not always obvious which ones do. Usually CLOCK_MONOTONIC is a good option, but you should test this on your own system.

для замера RTT ну за глаза

9.6ns ipg у десятки

Так что пусть идут со своим вдсо нахуй

а так можно?

10ns же hpet

или есть еще пизже?

таймстампинг видимо аппаратный...

в сетевухе