Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 2 [3]  Все   Вниз
  Печать  
Автор Тема: сбор данны по сети  (Прочитано 44515 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #60 : 11-06-2013 10:55 » 

Да сколько можно намекать?

Какая пропускная способность канала?
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
darkelf
Молодой специалист

ua
Offline 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
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #62 : 11-06-2013 11:06 » 

ну так я ж привел приблизительный расчет.
Я всегда уменьшаю, округляю, как говорил мой преподаватель по ТАУ - меня не интересует точность ваших расчетов до 6 знака. У вас погрешность  измерителей 2%.
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
sss
Специалист

ru
Offline Offline

« Ответ #63 : 11-06-2013 11:08 » 

Вообще хотя бы пинг с 600 байтным пакетом
Записан

while (8==8)
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #64 : 11-06-2013 12:03 » 

Ну вот я свой wi-fi маршрутизатор по стандарту n (до 600 Мб/с), находящийся от меня в паре метров, пингую: начиная с пакета 1200 и времени отклика 1 мс дальнейшее увеличение пакета ведёт к такому же линейному возрастанию времени отклика. 2400 - 2 мс, 4800 - 4 мс, 9600 - 7 мс, 19200 - 13 мс и т.д. При этом у меня в эфире висит 15 точек доступа и, очевидно, не меньшее число клиентов.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #65 : 11-06-2013 12:31 » 

Э... не путайте ТС

...........

Как заставить транспорт передать только один пакет получателю?

Предлагаю первейшим делом не пользоваться термином «пакет». Это снимет главную проблему данной темы.

Проблема ТС решается типовым алгоритмом: читать пока не наберется 600 байт.


Добавлено через 4 минуты и 37 секунд:
Итак:
- Какова реальная (наблюдаемая на практике) пропускная способность канала? Сомневаюсь, что там 54 Мб/с (802.11g) или 600 Мб/с (802.11n).
- Какова расчётная пропускная способность канала по условию задачи? Каждую мс по 600 байт 600 000 байт/сек чистых + ну скажем 50% для худшего случая служебного трафика самих сетевых протоколов (разных заголовков, пингов, синхронизаций, повторной передачи битых пакетов и т.п.) - итого округлим до примерно 1 Мб/сек или примерно 8 Мбит/с. Что, в общем-то с большим запасом позволяет любой современный транспорт на близкой дистанции.
- Каковы допустимые задержки при передачи (от момента начала отправки до момента конца получения блока в 600 байт)?
Данный вопрос я уже поднимал. И т.к. некогда детально изучал протокол (на тот момент максимум был 54 Мбит/с), то описал предстоящие трудности и сделал свои оценки: http://forum.shelek.ru/index.php/topic,29445.msg289140.html#msg289140

Добавлено через 5 минут и 3 секунды:
Да сколько можно намекать?

Какая пропускная способность канала?

В первом посте сказано, что 50 Мбит/с. Т.к. таковой скорости не значится в стандартах, предполагаю, что речь о 54 Мбит/с.
« Последнее редактирование: 11-06-2013 12:41 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #66 : 11-06-2013 13:00 » 

Цитата: RXL
Проблема ТС решается типовым алгоритмом: читать пока не наберется 600 байт.
Проблема может быть ещё и в обработке. Тогда решение будет: читать в одной нити во внутреннюю очередь, а в в другой нити обрабатывать. Ибо каждый запрос на чтение - это, вообще, обращение процесса к ядру, что в масштабе времени 1 мс может быть критичным. И поэтому может возникнуть потребность делать это пореже, читая/записывая много блоков разом - буферизация ввода-вывода.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #67 : 11-06-2013 13:04 » 

50 и 54 - не важно и я сказал почему. Для оценки пропускной способности канала

50мбит /10  чтоб получить количество байт в секунду.

получили 5мБ/с - не ошибся?

"блок данных" = 600 байт

считаем сколько таких блоков можем пропустить?
8000 блоков в секунду - не ошибся?




Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
darkelf
Молодой специалист

ua
Offline 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
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #69 : 11-06-2013 13:40 » 

фух... пост №68 Улыбаюсь
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
locator
Постоялец

ru
Offline Offline

« Ответ #70 : 12-06-2013 14:20 » 

я тут подумал, нельзя ли реально посмотреть объем информации, которую
получает приемник (сервер то есть)? сам я такую прогу вряд ли напишу,
может какие стандартные проги есть? желательно, что бы была возможность
как в терминале-  каждый байт записать в файл, а потом поглядеть, что же в файле.
Записан
darkelf
Молодой специалист

ua
Offline 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
Специалист

ru
Offline Offline

« Ответ #72 : 13-06-2013 01:53 » 

Правильно - записать каждый байт, не IP пакет... А то вдруг TCP и всё, хана, пропал дом..
« Последнее редактирование: 13-06-2013 01:58 от sss » Записан

while (8==8)
sss
Специалист

ru
Offline Offline

« Ответ #73 : 13-06-2013 02:01 » 

locator, не помогут всякие wincap. В лучшем случае увидите лог разбитый на "блоки данных" IP, которые надо будет ещё сшивать в поток. Там будут и повторы передач, и регулирование окон и бог его знает что ещё.  
Записан

while (8==8)
locator
Постоялец

ru
Offline Offline

« Ответ #74 : 13-06-2013 05:15 » 

darkelf, программа отличная, все что льется в сеть - видно! к тому же еще исходниками.
видно, что мои данные режутся на пакеты размером 1460 байт и 616 байт.
никаких повторов и пропусков не наблюдается. передача идет сильно неравномерно:
много промежуточных пакетов по 70 байт натыкано, и еще какие-то загадочные
пакеты нулевой длины с локального ноута. Я полагаю равномерным такой сбор
данных никогда не сделать.
В передающем потоке поставил Sleep(0), получил обновление данных 815 раз/с.
Большего от данного соединения наверное не получить, но этот результат меня очень
устраивает!
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #75 : 13-06-2013 06:56 » 

50 и 54 - не важно и я сказал почему. Для оценки пропускной способности канала

50мбит /10  чтоб получить количество байт в секунду.

получили 5мБ/с - не ошибся?

"блок данных" = 600 байт

считаем сколько таких блоков можем пропустить?
8000 блоков в секунду - не ошибся?

Слав, ты ошибся.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
darkelf
Молодой специалист

ua
Offline Offline

« Ответ #76 : 13-06-2013 07:31 » 

darkelf, программа отличная, все что льется в сеть - видно! к тому же еще исходниками.
В передающем потоке поставил Sleep(0), получил обновление данных 815 раз/с.
Большего от данного соединения наверное не получить, но этот результат меня очень
устраивает!
Как вариант - если потери данных не критичны - попробуйте перейти на UDP - будет шанс получить больший поток за счёт отсутствия ожидания подтверждения, но если приёмник будет не успевать обрабатывать данные, или будут какие помехи - данные будут теряться.
Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #77 : 13-06-2013 07:57 » 

darkelf, на Wi-Fi UDP - это всегда стрёмно, поскольку не управляешь факторами внешних влияний на сеть. Это по проводу, особенно экранированному, можно более-менее с большой вероятностью быть уверенным.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
locator
Постоялец

ru
Offline Offline

« Ответ #78 : 13-06-2013 08:29 » 

обязательно попробую, для целостности данных можно ведь считать crc.
если будет много ошибок, ну значит не судьба.
Записан
darkelf
Молодой специалист

ua
Offline Offline

« Ответ #79 : 13-06-2013 08:32 » 

locator, сами данные портится не будут, точнее если будут, то Вы об этом не узнаете - там сам стек считает контрольные суммы, и если что-то не сошлось, то сообщения отбрасываются. Узнать о том, что пакеты побились можно только по их отсутствию.
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #80 : 13-06-2013 08:43 » 

darkelf, на Wi-Fi UDP - это всегда стрёмно, поскольку не управляешь факторами внешних влияний на сеть. Это по проводу, особенно экранированному, можно более-менее с большой вероятностью быть уверенным.

Приходилось лет 10 назад писать логер для UDP-протокола. Т.к. данные после предобработки загружались в БД, то опасался возможной потери. По этому реализовал следующую архитектуру: приложение многопоточное (приемник, диспетчер, обработчик, две очереди — приема и обработки) прием осуществляется в очередь. Если очередь обработки заполнена ниже порога, диспетчер перебрасывает данные из очереди приема в очередь обработки. Если очередь обработки заполнена, а очередь приема выросла больше порога, создается временный файл в спец.директории и туда сбрасываются данные из приемной очереди, когда очередь на обработку опустеет, сперва подкачаются данные из временных файлов (также при запуске приложения). Система очередей позволяла оперативно принимать большой поток, система с файлами позволяла сглаживать блокировки БД (например при постобработке данных). Для теста искусственно создавал блокировку БД и в буферах в памяти и в файлах накапливалось до сотен МБ и после снятия блокировки все обработалось без потерь. Если памяти достаточно много и гарантия доставки не нужна, то можно обойтись без файлов — только очередь заданий в памяти.

Что-то я неправильно сперва понял процитированое: «на Wi-Fi UDP». Поддерживаю: WiFi дает низкую надежность и для гарантии доставки нужны подтверждения, что съедает плюсы над TCP.
« Последнее редактирование: 13-06-2013 08:47 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
sss
Специалист

ru
Offline Offline

« Ответ #81 : 13-06-2013 08:50 » 

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

И про очереди RXL правильно сказал - по другому асинхронно никак.

Хотя вроде уже всё устраивает?
« Последнее редактирование: 13-06-2013 08:53 от sss » Записан

while (8==8)
locator
Постоялец

ru
Offline Offline

« Ответ #82 : 14-06-2013 03:42 » 

В плане обмена все пока работает.  Еще один момент: если мне надо
знать интервал времени между последовательными приемами (всей
структуры данных), то лучше наверное включить время в состав этой
структуры? На приемном сервере время смысла нет измерять.
Записан
sss
Специалист

ru
Offline Offline

« Ответ #83 : 14-06-2013 03:51 » 

знать интервал времени между последовательными приемами

Где его ещё можно измерить как не на приёмной стороне?
Записан

while (8==8)
locator
Постоялец

ru
Offline Offline

« Ответ #84 : 14-06-2013 05:35 » 

можно там где данные сформировались пред передачей, засечь момент времени и запомнить его.
на приемной стороне все склеивается из разрезанных частей, где тут время считать?
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #85 : 14-06-2013 06:46 » 

Я бы фиксировал время и размер на стороне источника. Лучше данные структуировать, чем ориентироваться на фиксированные блоки. Гибче будет.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #86 : 14-06-2013 06:50 » 

в твой  блок данных подключай время.
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #87 : 14-06-2013 07:17 » 

Так может и подобие real time не нужно будет, раз время в логах записано.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
locator
Постоялец

ru
Offline Offline

« Ответ #88 : 17-06-2013 04:13 » 

воткнул время в структуру данных, все нормально считается: t = GetTickCount().
ну понятно, с точностью времени расчета самих данных. а если у считающего
данные потока повысить приоритет, время точнее будет определяться?
Записан
darkelf
Молодой специалист

ua
Offline Offline

« Ответ #89 : 17-06-2013 05:11 » 

воткнул время в структуру данных, все нормально считается: t = GetTickCount().
ну понятно, с точностью времени расчета самих данных. а если у считающего
данные потока повысить приоритет, время точнее будет определяться?
повысить точность можно через API мультимедиа-таймеров, см. timeBeginPeriod()
Записан
Страниц: 1 2 [3]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines