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

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 2 [3]  Все   Вниз
  Печать  
Автор Тема: сбор данны по сети  (Прочитано 106080 раз)
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 Мбит/с), то описал предстоящие трудности и сделал свои оценки: https://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