crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

2 страниц V  < 1 2  
Ответить в данную темуНачать новую тему
kuzulis
  опции профиля:
сообщение 10.12.2013, 17:24
Сообщение #11


Активный участник
***

Группа: Участник
Сообщений: 393
Регистрация: 29.6.2009
Пользователь №: 862

Спасибо сказали: 36 раз(а)




Репутация:   7  


А, ну понятно теперь..

Цитата
Собсна, вопрос главный был таков, можно ли как-то реализовать что-то существенно лучшее, чем в примере из трех строчек, который я привел.

Наврятли что-то лучшее. Если только заменить на QDateTime::currentMSecsSinceEpoch(). :)
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
mezmay
  опции профиля:
сообщение 11.12.2013, 13:52
Сообщение #12


Активный участник
***

Группа: Участник
Сообщений: 272
Регистрация: 13.7.2009
Из: Ростов-на-Дону
Пользователь №: 904

Спасибо сказали: 16 раз(а)




Репутация:   1  


По умолчанию скорость отправки пакета по сокету довольно медленная, если не отключать алгоритм Нейгла:
http://ru.wikipedia.org/wiki/Алгоритм_Нейгла

в Qt отключается с помощью QAbstractSocket::setSocketOption
использование:
socket->setSocketOption(QAbstractSocket::LowDelayOption, 1);


это так, к сведению, на случай если нужна какая-то более-менее адекватная скорость

Сообщение отредактировал mezmay - 11.12.2013, 13:58
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
gormih
  опции профиля:
сообщение 19.12.2013, 15:32
Сообщение #13


Студент
*

Группа: Новичок
Сообщений: 15
Регистрация: 22.9.2011
Пользователь №: 2901

Спасибо сказали: 0 раз(а)




Репутация:   0  


Цитата(Iron Bug @ 10.12.2013, 10:04) *
Цитата(gormih @ 10.12.2013, 2:41) *
До некоторой степени точные данные можно было бы получить используя например низкоуровневые функции в Linux (работая по сути на уровне ядра системы) - но это уже далеко не QT и его сокеты :-)

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

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


Все правильно - существуют буфера как внутри сетевой карты, так и внутри пространства драйвера ОС.
Если рассматривать задачу на уровне исключения влияния планировщика ОС (который вносит некоторое рандомное значение по времени обработки) - то я бы просто допилил драйвер конкретной сетевой карты в драйвере 1го уровня - дал бы ему задачу присовокуплять к записанным данным в буфер еще и информацию о точном системном времени. В дальнейшем эту инфу использовать при разборке пакетов на уровне стеков протоколов.
Кстати, не факт что этой информации там уже нет :-)
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

2 страниц V  < 1 2
Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


8 чел. читают эту тему (гостей: 8, скрытых пользователей: 0)
Пользователей: 0


RSS Рейтинг@Mail.ru Текстовая версия Сейчас: 18.2.2025, 17:22