Sla
|
|
« Ответ #60 : 11-06-2013 10:55 » |
|
Да сколько можно намекать?
Какая пропускная способность канала?
|
|
|
Записан
|
Мы все учились понемногу... Чему-нибудь и как-нибудь.
|
|
|
darkelf
Молодой специалист
Offline
|
|
« Ответ #61 : 11-06-2013 10:58 » |
|
Ну... тут скорей нужна математика.
50Мбит/с ~ 5Мб/с
делим на 600, получаем 8000 пакетов в сек
зы... я не ошибся в расчетах?
Та какая разница, какого размер тик. Пусть будет какой будет. Я где-то в расчете ошибся? там, кроме 600 байтов пользовательских данных, будет ещё заголовок TCP (минимум 20 байт), заголовок IP (20 майт), к сожалению не знаю, как в wi-fi, но у ethernet будет ещё MAC-загловок (минимум 22 байта) и его контрольная сумма и межфреймовое пространство (16 байт), т.е. на каждые пользовательские 600 байтов будут расходоваться минимум ещё 80 байт. Далее, т.к. это tcp/ip, а не udp, то тут ещё будет квитирование, т.е. передали данные и ждём подтверждение и так практически на каждое сообщение. Обратно будет идти гораздо меньше данных, но т.к. это запрос-ответ - передающей стороне придётся ждать. Да и как говорил Dimka у самого wi-fi может быть много всяких своих заморочек типа помех.
|
|
|
Записан
|
|
|
|
Sla
|
|
« Ответ #62 : 11-06-2013 11:06 » |
|
ну так я ж привел приблизительный расчет. Я всегда уменьшаю, округляю, как говорил мой преподаватель по ТАУ - меня не интересует точность ваших расчетов до 6 знака. У вас погрешность измерителей 2%.
|
|
|
Записан
|
Мы все учились понемногу... Чему-нибудь и как-нибудь.
|
|
|
sss
Специалист
Offline
|
|
« Ответ #63 : 11-06-2013 11:08 » |
|
Вообще хотя бы пинг с 600 байтным пакетом
|
|
|
Записан
|
while (8==8)
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #64 : 11-06-2013 12:03 » |
|
Ну вот я свой wi-fi маршрутизатор по стандарту n (до 600 Мб/с), находящийся от меня в паре метров, пингую: начиная с пакета 1200 и времени отклика 1 мс дальнейшее увеличение пакета ведёт к такому же линейному возрастанию времени отклика. 2400 - 2 мс, 4800 - 4 мс, 9600 - 7 мс, 19200 - 13 мс и т.д. При этом у меня в эфире висит 15 точек доступа и, очевидно, не меньшее число клиентов.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
RXL
|
|
« Ответ #65 : 11-06-2013 12:31 » |
|
Э... не путайте ТС
...........
Как заставить транспорт передать только один пакет получателю?
Предлагаю первейшим делом не пользоваться термином «пакет». Это снимет главную проблему данной темы. Проблема ТС решается типовым алгоритмом: читать пока не наберется 600 байт. Добавлено через 4 минуты и 37 секунд:Итак: - Какова реальная (наблюдаемая на практике) пропускная способность канала? Сомневаюсь, что там 54 Мб/с (802.11g) или 600 Мб/с (802.11n). - Какова расчётная пропускная способность канала по условию задачи? Каждую мс по 600 байт 600 000 байт/сек чистых + ну скажем 50% для худшего случая служебного трафика самих сетевых протоколов (разных заголовков, пингов, синхронизаций, повторной передачи битых пакетов и т.п.) - итого округлим до примерно 1 Мб/сек или примерно 8 Мбит/с. Что, в общем-то с большим запасом позволяет любой современный транспорт на близкой дистанции. - Каковы допустимые задержки при передачи (от момента начала отправки до момента конца получения блока в 600 байт)?
Данный вопрос я уже поднимал. И т.к. некогда детально изучал протокол (на тот момент максимум был 54 Мбит/с), то описал предстоящие трудности и сделал свои оценки: https://forum.shelek.ru/index.php/topic,29445.msg289140.html#msg289140Добавлено через 5 минут и 3 секунды:Да сколько можно намекать?
Какая пропускная способность канала?
В первом посте сказано, что 50 Мбит/с. Т.к. таковой скорости не значится в стандартах, предполагаю, что речь о 54 Мбит/с.
|
|
« Последнее редактирование: 11-06-2013 12:41 от RXL »
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #66 : 11-06-2013 13:00 » |
|
Проблема ТС решается типовым алгоритмом: читать пока не наберется 600 байт. Проблема может быть ещё и в обработке. Тогда решение будет: читать в одной нити во внутреннюю очередь, а в в другой нити обрабатывать. Ибо каждый запрос на чтение - это, вообще, обращение процесса к ядру, что в масштабе времени 1 мс может быть критичным. И поэтому может возникнуть потребность делать это пореже, читая/записывая много блоков разом - буферизация ввода-вывода.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
Sla
|
|
« Ответ #67 : 11-06-2013 13:04 » |
|
50 и 54 - не важно и я сказал почему. Для оценки пропускной способности канала
50мбит /10 чтоб получить количество байт в секунду.
получили 5мБ/с - не ошибся?
"блок данных" = 600 байт
считаем сколько таких блоков можем пропустить? 8000 блоков в секунду - не ошибся?
|
|
|
Записан
|
Мы все учились понемногу... Чему-нибудь и как-нибудь.
|
|
|
darkelf
Молодой специалист
Offline
|
|
« Ответ #68 : 11-06-2013 13:24 » |
|
Если верить http://www.fotonx.ru/index.php/2011-08-17-12-36-50/76--wi-fi.html, то реальная скорость 54Мбит/с и даже 50Мбит/с быть не может, а будет максимум до 24Мбит/с. Ну а дальше, как уже говорилось, накладные расходы, roundtrip-ы в tcp/ip и прочие радости. Возможно 1000 пакетов в секунду можно будет и не набрать.
|
|
|
Записан
|
|
|
|
Sla
|
|
« Ответ #69 : 11-06-2013 13:40 » |
|
фух... пост №68
|
|
|
Записан
|
Мы все учились понемногу... Чему-нибудь и как-нибудь.
|
|
|
locator
Постоялец
Offline
|
|
« Ответ #70 : 12-06-2013 14:20 » |
|
я тут подумал, нельзя ли реально посмотреть объем информации, которую получает приемник (сервер то есть)? сам я такую прогу вряд ли напишу, может какие стандартные проги есть? желательно, что бы была возможность как в терминале- каждый байт записать в файл, а потом поглядеть, что же в файле.
|
|
|
Записан
|
|
|
|
darkelf
Молодой специалист
Offline
|
|
« Ответ #71 : 12-06-2013 14:30 » |
|
locator, wireshark/windump. Winpcap, через которую работают данные программы что-то там вроде умела, правда судя по FAQ ( http://www.winpcap.org/misc/faq.htm#Q-16) - работает это не всегда.
|
|
« Последнее редактирование: 12-06-2013 14:36 от darkelf »
|
Записан
|
|
|
|
sss
Специалист
Offline
|
|
« Ответ #72 : 13-06-2013 01:53 » |
|
Правильно - записать каждый байт, не IP пакет... А то вдруг TCP и всё, хана, пропал дом..
|
|
« Последнее редактирование: 13-06-2013 01:58 от sss »
|
Записан
|
while (8==8)
|
|
|
sss
Специалист
Offline
|
|
« Ответ #73 : 13-06-2013 02:01 » |
|
locator, не помогут всякие wincap. В лучшем случае увидите лог разбитый на "блоки данных" IP, которые надо будет ещё сшивать в поток. Там будут и повторы передач, и регулирование окон и бог его знает что ещё.
|
|
|
Записан
|
while (8==8)
|
|
|
locator
Постоялец
Offline
|
|
« Ответ #74 : 13-06-2013 05:15 » |
|
darkelf, программа отличная, все что льется в сеть - видно! к тому же еще исходниками. видно, что мои данные режутся на пакеты размером 1460 байт и 616 байт. никаких повторов и пропусков не наблюдается. передача идет сильно неравномерно: много промежуточных пакетов по 70 байт натыкано, и еще какие-то загадочные пакеты нулевой длины с локального ноута. Я полагаю равномерным такой сбор данных никогда не сделать. В передающем потоке поставил Sleep(0), получил обновление данных 815 раз/с. Большего от данного соединения наверное не получить, но этот результат меня очень устраивает!
|
|
|
Записан
|
|
|
|
RXL
|
|
« Ответ #75 : 13-06-2013 06:56 » |
|
50 и 54 - не важно и я сказал почему. Для оценки пропускной способности канала
50мбит /10 чтоб получить количество байт в секунду.
получили 5мБ/с - не ошибся?
"блок данных" = 600 байт
считаем сколько таких блоков можем пропустить? 8000 блоков в секунду - не ошибся?
Слав, ты ошибся.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
darkelf
Молодой специалист
Offline
|
|
« Ответ #76 : 13-06-2013 07:31 » |
|
darkelf, программа отличная, все что льется в сеть - видно! к тому же еще исходниками. В передающем потоке поставил Sleep(0), получил обновление данных 815 раз/с. Большего от данного соединения наверное не получить, но этот результат меня очень устраивает!
Как вариант - если потери данных не критичны - попробуйте перейти на UDP - будет шанс получить больший поток за счёт отсутствия ожидания подтверждения, но если приёмник будет не успевать обрабатывать данные, или будут какие помехи - данные будут теряться.
|
|
|
Записан
|
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #77 : 13-06-2013 07:57 » |
|
darkelf, на Wi-Fi UDP - это всегда стрёмно, поскольку не управляешь факторами внешних влияний на сеть. Это по проводу, особенно экранированному, можно более-менее с большой вероятностью быть уверенным.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
locator
Постоялец
Offline
|
|
« Ответ #78 : 13-06-2013 08:29 » |
|
обязательно попробую, для целостности данных можно ведь считать crc. если будет много ошибок, ну значит не судьба.
|
|
|
Записан
|
|
|
|
darkelf
Молодой специалист
Offline
|
|
« Ответ #79 : 13-06-2013 08:32 » |
|
locator, сами данные портится не будут, точнее если будут, то Вы об этом не узнаете - там сам стек считает контрольные суммы, и если что-то не сошлось, то сообщения отбрасываются. Узнать о том, что пакеты побились можно только по их отсутствию.
|
|
|
Записан
|
|
|
|
RXL
|
|
« Ответ #80 : 13-06-2013 08:43 » |
|
darkelf, на Wi-Fi UDP - это всегда стрёмно, поскольку не управляешь факторами внешних влияний на сеть. Это по проводу, особенно экранированному, можно более-менее с большой вероятностью быть уверенным.
Приходилось лет 10 назад писать логер для UDP-протокола. Т.к. данные после предобработки загружались в БД, то опасался возможной потери. По этому реализовал следующую архитектуру: приложение многопоточное (приемник, диспетчер, обработчик, две очереди — приема и обработки) прием осуществляется в очередь. Если очередь обработки заполнена ниже порога, диспетчер перебрасывает данные из очереди приема в очередь обработки. Если очередь обработки заполнена, а очередь приема выросла больше порога, создается временный файл в спец.директории и туда сбрасываются данные из приемной очереди, когда очередь на обработку опустеет, сперва подкачаются данные из временных файлов (также при запуске приложения). Система очередей позволяла оперативно принимать большой поток, система с файлами позволяла сглаживать блокировки БД (например при постобработке данных). Для теста искусственно создавал блокировку БД и в буферах в памяти и в файлах накапливалось до сотен МБ и после снятия блокировки все обработалось без потерь. Если памяти достаточно много и гарантия доставки не нужна, то можно обойтись без файлов — только очередь заданий в памяти. Что-то я неправильно сперва понял процитированое: «на Wi-Fi UDP». Поддерживаю: WiFi дает низкую надежность и для гарантии доставки нужны подтверждения, что съедает плюсы над TCP.
|
|
« Последнее редактирование: 13-06-2013 08:47 от RXL »
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
sss
Специалист
Offline
|
|
« Ответ #81 : 13-06-2013 08:50 » |
|
Надо просто перейти от синхронного вызова send к асинхронному и при этом остаться в TCP.. TCP пошлёт все как надо - сериями. Подтверждения будут на всю серию.
И про очереди RXL правильно сказал - по другому асинхронно никак.
Хотя вроде уже всё устраивает?
|
|
« Последнее редактирование: 13-06-2013 08:53 от sss »
|
Записан
|
while (8==8)
|
|
|
locator
Постоялец
Offline
|
|
« Ответ #82 : 14-06-2013 03:42 » |
|
В плане обмена все пока работает. Еще один момент: если мне надо знать интервал времени между последовательными приемами (всей структуры данных), то лучше наверное включить время в состав этой структуры? На приемном сервере время смысла нет измерять.
|
|
|
Записан
|
|
|
|
sss
Специалист
Offline
|
|
« Ответ #83 : 14-06-2013 03:51 » |
|
знать интервал времени между последовательными приемами
Где его ещё можно измерить как не на приёмной стороне?
|
|
|
Записан
|
while (8==8)
|
|
|
locator
Постоялец
Offline
|
|
« Ответ #84 : 14-06-2013 05:35 » |
|
можно там где данные сформировались пред передачей, засечь момент времени и запомнить его. на приемной стороне все склеивается из разрезанных частей, где тут время считать?
|
|
|
Записан
|
|
|
|
RXL
|
|
« Ответ #85 : 14-06-2013 06:46 » |
|
Я бы фиксировал время и размер на стороне источника. Лучше данные структуировать, чем ориентироваться на фиксированные блоки. Гибче будет.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Sla
|
|
« Ответ #86 : 14-06-2013 06:50 » |
|
в твой блок данных подключай время.
|
|
|
Записан
|
Мы все учились понемногу... Чему-нибудь и как-нибудь.
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #87 : 14-06-2013 07:17 » |
|
Так может и подобие real time не нужно будет, раз время в логах записано.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
locator
Постоялец
Offline
|
|
« Ответ #88 : 17-06-2013 04:13 » |
|
воткнул время в структуру данных, все нормально считается: t = GetTickCount(). ну понятно, с точностью времени расчета самих данных. а если у считающего данные потока повысить приоритет, время точнее будет определяться?
|
|
|
Записан
|
|
|
|
darkelf
Молодой специалист
Offline
|
|
« Ответ #89 : 17-06-2013 05:11 » |
|
воткнул время в структуру данных, все нормально считается: t = GetTickCount(). ну понятно, с точностью времени расчета самих данных. а если у считающего данные потока повысить приоритет, время точнее будет определяться?
повысить точность можно через API мультимедиа-таймеров, см. timeBeginPeriod()
|
|
|
Записан
|
|
|
|
|