forum.wfido.ru  

Вернуться   forum.wfido.ru > Прочие эхи > RU.ARGUS

Ответ
 
Опции темы Опции просмотра
  #11  
Старый 17.08.2016, 16:37
Oleg Redut
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Oleg Redut написал(а) к Vladimir Bakhvaloff в Feb 16 12:14:46 по местному времени:

Доброе (current) время суток, Vladimir!

VB> Для начала - не мучать виртуалки...
VB> Для продолжения - взять Тау по-новее...

А что у нас считается более новее?
У меня
Taurus v.5.112.2009.64/Winter/FastMM 4.94/DEBUG
При штатном выходе: меню -> Exit вылетает

=== Вырезка из филе Windows Clipboard ===
---------------------------2016/2/22 12:13:40-----------------------
FastMM обнаружил попытку вызвать виртуальный метод освобожденного объекта. Сейчас будет вызвано нарушение доступа для прерывания текущей операции.

Класс освобожденного объекта: TCronThreadLogger

Виртуальный метод: Destroy

Адрес виртуального метода: 404A30

Выделенный номер был: 9278

The object was allocated by thread 0xD60, and the stack trace (return addresses) at the time was:
402E60 [system.pas][System][@GetMem][2439]
=== Кончилась врезка ===

Последующие тестовые сборки, помнится, так и не заработали, затыкаясь на множественных входящих и не закрывающихся сессиях.

Что я могу еще сказать?..
Oleg

... AKA oleg(&)redut.info AKA ICQ 28852595
--- GoldED+/W32-MINGW 1.1.5-b20120515 (пока работает)
Ответить с цитированием
  #12  
Старый 17.08.2016, 16:37
Alexey Korotkov
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Alexey Korotkov написал(а) к Vladimir Bakhvaloff в Feb 16 19:52:40 по местному времени:

Привет Vladimir!

22-Фев-2016 00:10, Vladimir Bakhvaloff -> Alexey Korotkov:

AK>> Radius 4.010/январь 2005, binkd-mingw/1.0.1/w32, виртуалки
AK>> win2003.

VB> Для начала - не мучать виртуалки...
Вы, видимо, просто не умеете их готовить.

VB> Для продолжения - взять Тау по-новее...
Взял Tau.140708.1709.7z, начал сессию, файлы полились (вроде как даже не быстрей чем у радиуса). При попытке открыть вкладку tcp/ip1 таурус успешно падает практически сразу. Попробовал еще раз - результат тот же. На второй виртуалке те же яйца. Искать работоспособный турус желания нет, т.к. сложилось впечатление что изменение кода после радиуса 2005 года (грубо говоря) было не в пользу качества, а в сторону новых непонятных мне фитч.

PS Есть какой-нибудь курс молодого бойца по исходникам радиуса? Так чтобы не (проф.) программист разобрался.

Alexey
--- GoldED+/W32 1.1.5-021109
Ответить с цитированием
  #13  
Старый 17.08.2016, 16:37
Vladimir Bakhvaloff
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Vladimir Bakhvaloff написал(а) к Alexey Korotkov в Feb 16 18:23:44 по местному времени:

Удачной охоты, Alexey! (Кстати, а как пpошла пpедыдущая?)

Отвечая на письмо Alexey Korotkov => Vladimir Bakhvaloff [Пн 22 Фев 16]:

AK>>> Radius 4.010/январь 2005, binkd-mingw/1.0.1/w32, виртуалки
AK>>> win2003.
VB>> Для начала - не мучать виртуалки...
AK> Вы, видимо, просто не умеете их готовить.

Вполне...
Ни VMWare, ни VirtualBox, ни VirtualPC у меня не вызвали особой радости на Core2Duo с 4Гб мозгу... :-D

VB>> Для продолжения - взять Тау по-новее...
AK> Взял Tau.140708.1709.7z, начал сессию, файлы полились (вроде как
AK> даже не быстрей чем у радиуса). При попытке открыть вкладку tcp/ip1
AK> таурус успешно падает практически сразу.

Вот сколько ни пытался повторить, ну ни разу такого не было... :-(

AK> изменение кода после радиуса 2005 года (грубо говоря) было не в пользу
AK> качества, а в сторону новых непонятных мне фитч.

Были какие-то изменения и даже парочку каких-то падений даже вылечил... ;-)
Ну, попробуй взять http://bakhvaloff.ru/Download/Taurus/Tau.160223.1842.7z
В каталоге WODebug - без дебаговой информации, должно жить полегче...

AK> PS Есть какой-нибудь курс молодого бойца по исходникам радиуса? Так
AK> чтобы не (проф.) программист разобрался.

Сомневаюсь, что такой "ликбез" тебе кто-то сможет провести... :-D
Над тем, что есть сейчас работали, как минимум 6 человек... Причём с совершенно разными подходами...

С выражением глубокого почтения - Vladimir...
> ------------------------------------------------------------
Windows 7 Ultimate x86 [version 6.1.7601] Service Pack 1
Taurus v.5.114.2013.19/Autumn/FastMM 4.991/DEBUG
--- System uptime is: 23:59:49.564 (max. - 27 day(s) 6:38:31.123)
Ответить с цитированием
  #14  
Старый 17.08.2016, 16:37
Vladimir Bakhvaloff
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Vladimir Bakhvaloff написал(а) к Alexey Korotkov в Feb 16 19:07:18 по местному времени:

Удачной охоты, Alexey! (Кстати, а как пpошла пpедыдущая?)

Однажды, Вт 23 Фев 16 в 18:23:44, Vladimir Bakhvaloff
написал Alexey Korotkov, и я добавил:

VB> Ну, попробуй взять
VB> http://bakhvaloff.ru/Download/Taurus/Tau.160223.1842.7z

Заодно можешь поискать "конкурентов" - TrapGate на sf.net...

Да и хватит пока... Vladimir.
> ------------------------------------------------------------
Windows 7 Ultimate x86 [version 6.1.7601] Service Pack 1
Taurus v.5.114.2013.19/Winter/FastMM 4.991/DEBUG
--- System uptime is: 0:12:55.889 (max. - 27 day(s) 6:38:31.123)
Ответить с цитированием
  #15  
Старый 17.08.2016, 16:37
Alexey Korotkov
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Alexey Korotkov написал(а) к Vladimir Bakhvaloff в Feb 16 22:25:06 по местному времени:

Привет Vladimir!

23-Фев-2016 18:23, Vladimir Bakhvaloff -> Alexey Korotkov:

VB> Ни VMWare, ни VirtualBox, ни VirtualPC у меня не вызвали особой
VB> радости на Core2Duo с 4Гб мозгу... :-D
На домашнем ESXi 5.1 xeon e3-1240@3,4GНz и 32GB RAM при условии прямого софта и отсутствия излишней дисковой активности никаких проблем не испытываю ;-)

VB> Вот сколько ни пытался повторить, ну ни разу такого не было... :-(
похоже что валится тот экземпляр, который отправляет.

VB> Ну, попробуй взять
VB> http://bakhvaloff.ru/Download/Taurus/Tau.160223.1842.7z
VB> В каталоге WODebug - без дебаговой информации, должно жить
VB> полегче...
Даже с tcpackfrequency=1 что-то затыкается как будто этого параметра нет.
Для сравнения:
Чуток тюнингованный радиус (такая же версия отдает файлы)
23-Feb-2016 19:53:46 CONNECT To 192.168.0.212 #24554 (1:2/3)
23-Feb-2016 19:53:51 Disconnect from 192.168.0.212 - Complete (1:2/3) IN: 900 (11,700b) OUT: 0 (0b)
Данный таурус:
23-Feb-2016 20:21:09 CONNECT To 192.168.0.212 #24554 (1:2/3)
23-Feb-2016 20:22:20 Disconnect from 192.168.0.212 - Complete (1:2/3) IN: 900 (11,700b) OUT: 0 (0b)

VB> Сомневаюсь, что такой "ликбез" тебе кто-то сможет провести... :-D
VB> Над тем, что есть сейчас работали, как минимум 6 человек... Причём
VB> с совершенно разными подходами...
Оптимистичненько.... :-(

Пока что с помощью тюнинга реестра добился быстрой отдачи на сторону, где внесены изменения в реестр. Не густо, но хоть что-то. Проявилсь другая проблема: нелинейно возрастает загрузка процессора радиусом при увеличении количества отдаваемых файлов, достигая нездоровых значений (на стороне, которая передает файлы). Например, при количестве файлов 900 загрузка ядра процессора отдающей файлы стороны грубо говоря 0,6 клетки диспетчера задач, 1500- 2 клетки, 3000 - уже 14,5 клеток.
Наглядно передача 3000 файлов (с другим масштабом)
Без tcpackfrequency==1:
http://pikbox.ru/img/16/20160224024321439noack_3000.jpg
С установл. tcpackfrequency==1:
http://pikbox.ru/img/11/201602240251...</b>scale2.jpg
На второй картинке примерно та же картина, только радиус не растягивает сессию на 11,5 минут, а отрабатывает за полторы, и загружает процессор по полной.
По расчетам (если принять значение средней загрузки 17%) грубо получается: 3400*0,17/4,38 = 130 МГц ядра далеко нетупого процессора нужно потратить чтобы передать за одну секунду один файл размером 13 байт. Если расчитать сколько файлов сможет передать такой процессор(ядро) за секунду с таким софтом, то получим примерно 26 файлов. Это какой-то позор! (с).
Причем, это не ограничения протокола или железа, т.к. малое количество файлов пролетает на "ура" (500 файлов передалось за 2 секунды, а при 3000 файлов скорость падает до 22-26 файлов/сек)
Может подскажете что может таким образом (см. на форму графика загрузки) тормозить процесс?


Alexey
--- GoldED+/W32 1.1.5-021109
Ответить с цитированием
  #16  
Старый 17.08.2016, 16:37
Vladimir Bakhvaloff
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Vladimir Bakhvaloff написал(а) к Oleg Redut в Feb 16 17:39:38 по местному времени:

...я помню, кто вызвался идти первым, я знаю их имена...
Это были Oleg Redut и индеец Острие Бревна...

Отвечая на письмо Oleg Redut => Vladimir Bakhvaloff [Пт 26 Фев 16]:

VB>> http://bakhvaloff.ru/Download/Taurus/Tau.160223.1842.7z
OR> Сутки отстоял с дебагом. Вроде благополучно.

Работает - не трогай!.. ;-)

OR> Taurus v.5.114.2013.19/Winter
OR> Кстати, почему 2013?

Да я просто не компилирую последнее время с правкой ресурсов, в которых и прошит номер версии... ;-)

OR> Сейчас решил заменить без дебага - вылет.
OR> Windows 7 Ultimate x64 [version 6.1.7601] Service Pack 1
OR> === Вырезка из филе Windows Clipboard ===
OR> === Кончилась врезка ===

Пытались с Шахайло расколоть её две ночи подряд...
Ни разу не прёт...
Если запускаю под IDE, она просто не возникает...
Если просто запускать, то никак не понять, в каком конкретно месте...

Ладно... Пойду вешаться, Oleg... ;)
> ------------------------------------------------------------
Windows 7 Ultimate x86 [version 6.1.7601] Service Pack 1
Taurus v.5.114.2013.19/Winter/FastMM 4.991/DEBUG
--- System uptime is: 2 day(s) 22:45:09.450 (max. - 27 day(s) 6:38:31.123)
Ответить с цитированием
  #17  
Старый 17.08.2016, 16:37
Alexey Korotkov
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Alexey Korotkov написал(а) к Vladimir Bakhvaloff в Feb 16 22:13:58 по местному времени:

Привет Vladimir!

26-Фев-2016 17:36, Vladimir Bakhvaloff -> Alexey Korotkov:

VB> Тогда пусть некий "непрограммист" выдаст лёгкий и нежный патч для
VB> данной проблемы...
Не умею я патчи выдавать, могу в эхе нарисовать :-)

VB> Сами M$ говорят, что данный хак имеет непредсказуемые
VB> последствия... Можешь забыть...
где говорят?
https://support.microsoft.com/en-us/kb/823764
Slow performance occurs when you copy data to a TCP server by using a Windows Sockets API program.
даже приводит изменение реестра как одно из решений. Нигде про непредсказуемые последствия использования данного ключа реестра не говорится.

AK>> Если реестр не патчить, или не использовать шифрованные
AK>> соединения, то баг вроде как не проявляется, проверил на 100тыс
VB> Q.E.D...
Во-первых, стабильность работы (целостность данных) радиуса и компании не должна зависить от скорости работы сети. Я так понимаю. Если косяк есть, логично его исправить если есть возможность. Если косяк вылазит, значит где-то может что-то не так с памятью и данными. Хорошо если ошибка приводит только к разрыву сессии, а не к изменению втихую данных. Другое дело что может быть, для всех кроме меня десяток-другой файлов в секунду это норма, а там вроде как бага и не видно :-)
Во-вторых, мне чудом удалось поймать снифером аналогичное проявление бага и на нешифрованном канале. Кого-нибудь дамп трафика интересует?


Alexey
--- GoldED+/W32 1.1.5-021109
Ответить с цитированием
  #18  
Старый 17.08.2016, 16:37
Vladimir Bakhvaloff
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Vladimir Bakhvaloff написал(а) к Alexey Korotkov в Feb 16 22:57:44 по местному времени:

Как жизнь половая, Korotkov?..

Отвечая на письмо Alexey Korotkov => Vladimir Bakhvaloff [Пт 26 Фев 16]:

VB>> Тогда пусть некий "непрограммист" выдаст лёгкий и нежный патч
VB>> для данной проблемы...
AK> Не умею я патчи выдавать, могу в эхе нарисовать :-)

Да... Ты явно не ищешь лёгких путей...
То реестры патчить...
То передавать 10к мелких файлов, вместо их архивации в один...
То забыть, что есть нетмейл для ЛИЧНОЙ связи, а не пихать чемоданы траффика в эху... :-(

VB>> Сами M$ говорят, что данный хак имеет непредсказуемые
VB>> последствия... Можешь забыть...
AK> где говорят?
AK> https://support.microsoft.com/en-us/kb/823764
AK> Slow performance occurs when you copy data to a TCP server by using a

Где-то там же...
Меня совсем не интересуют заклинания под бубен...
Программа должна работать БЕЗ них... И работает...

AK>>> Если реестр не патчить, или не использовать шифрованные
AK>>> соединения, то баг вроде как не проявляется, проверил на 100тыс
VB>> Q.E.D...
AK> Во-первых, стабильность работы (целостность данных) радиуса и
AK> компании не должна зависить от скорости работы сети.

Именно так и есть...

AK> Я так понимаю.
AK> Если косяк есть, логично его исправить если есть возможность.

Нет косяка...

AK> видно :-) Во-вторых, мне чудом удалось поймать снифером аналогичное
AK> проявление бага и на нешифрованном канале. Кого-нибудь дамп трафика
AK> интересует?

Да... ФСБ...

...и, прищурившись, как Клинт Иствуд, Vladimir Bakhvaloff посмотрел Alexey Korotkov вслед...
> ------------------------------------------------------------
Windows 7 Ultimate x86 [version 6.1.7601] Service Pack 1
Taurus v.5.114.2013.19/Winter/FastMM 4.991/DEBUG
--- System uptime is: 3 day(s) 4:03:15.386 (max. - 27 day(s) 6:38:31.123)
Ответить с цитированием
  #19  
Старый 17.08.2016, 16:37
Alexey Korotkov
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Alexey Korotkov написал(а) к Vladimir Bakhvaloff в Feb 16 23:11:54 по местному времени:

Привет Vladimir!

26-Фев-2016 22:57, Vladimir Bakhvaloff -> Alexey Korotkov:

VB> Да... Ты явно не ищешь лёгких путей...
VB> То реестры патчить...
VB> То передавать 10к мелких файлов, вместо их архивации в один...
VB> То забыть, что есть нетмейл для ЛИЧНОЙ связи, а не пихать чемоданы
VB> траффика в эху... :-(
1. Про мои пути: есть потребности, граничные условия и проблемы, поэтому проблемы все же нужно решать в этих граничных условиях. А они таковы, что это должен быть именно Radius, файлы паковать нельзя, и количество файлов для обмена может быть не то что 10k, а даже 100k+. Как ни странно, FTN-технология рулит в этом плане по сравнению с современными поделками.
2. Нетмейл - это значит что информация попадет только к одному человеку. А может быть она еще кому-то тоже будет актуальна для исправления радиуса?
3. Чемоданов трафика в эхе не планируется. Да и неужели сейчас существует проблема избытка в эхе трафика?

VB> Где-то там же...
VB> Меня совсем не интересуют заклинания под бубен...
VB> Программа должна работать БЕЗ них... И работает...
Ну, если брать использование радиуса чисто под фиду, то да. Но если использовать его для других задач, то проявляется явно недостаточная скорость и дикий жор процессора из коробки.

AK>> Во-первых, стабильность работы (целостность данных) радиуса и
AK>> компании не должна зависить от скорости работы сети.
VB> Именно так и есть...
А вот фиг вам. Если ставить галку в настройках протокола Binkp "требовать шифрование", то у меня даже версия отцов-основателей (2005г.) уходит в затык при попытке установить сессию. Если параметры реестра поменять на обоих сторонах, то сессии начинают успешно устанавливаться. Что я делаю не так? (Но мне это пока что не актуально, и поэтому я повторно не проверял после своих последних изменений)

AK>> Я так понимаю.
AK>> Если косяк есть, логично его исправить если есть возможность.
VB> Нет косяка...
И снова фиг вам :-) Нашел и исправил. Радиус думал что данные могут приходить по чуть-ть, и что он работает быстрей поступления данных. А они неожиданно приходили в процессе его работы..
Уже прокачал несколько раз по 100тыс файлов на криптованной сессии, ни единого разрыва! (с)

AK>> Кого-нибудь дамп трафика интересует?
VB> Да... ФСБ...
Как скажешь.

Alexey
--- GoldED+/W32 1.1.5-021109
Ответить с цитированием
  #20  
Старый 17.08.2016, 16:37
Vladimir Bakhvaloff
Guest
 
Сообщений: n/a
По умолчанию Низкая скорость отправки большого количества мелких файлов

Vladimir Bakhvaloff написал(а) к Alexey Korotkov в Feb 16 09:23:06 по местному времени:

Saludo, comarado Alexey!

Отвечая на письмо Alexey Korotkov => Vladimir Bakhvaloff [Сб 27 Фев 16]:

VB>> Да... Ты явно не ищешь лёгких путей...
VB>> То реестры патчить...
VB>> То передавать 10к мелких файлов, вместо их архивации в
VB>> один...
VB>> То забыть, что есть нетмейл для ЛИЧНОЙ связи, а не пихать
VB>> чемоданы траффика в эху... :-(
AK> 1. Про мои пути: есть потребности, граничные условия и проблемы,
AK> поэтому проблемы все же нужно решать в этих граничных условиях. А они
AK> таковы, что это должен быть именно Radius, файлы паковать нельзя, и
AK> количество файлов для обмена может быть не то что 10k, а даже 100k+.
AK> Как ни странно, FTN-технология рулит в этом плане по сравнению с
AK> современными поделками.

Не ве-рю!!! /К.С. Станиславский/
Правильно поставленная задача решает больше половины проблем...
Ну не может Radius (чиста канкретна) быть крайним решением!.. :-D
Тебе просто лень разнести передачу "фирменных" файлов и фидошку по разным портам...

AK> 2. Нетмейл - это значит что информация попадет только к одному
AK> человеку. А может быть она еще кому-то тоже будет актуальна для
AK> исправления радиуса?

Сначала надо быть уверенным, что это действительно так... А потом - сохрани в свой загашник...

AK> 3. Чемоданов трафика в эхе не планируется. Да и неужели сейчас
AK> существует проблема избытка в эхе трафика?

Трафика?.. Нет, естественно!..
Проблема "лишних знаний" - да...

VB>> Где-то там же...
VB>> Меня совсем не интересуют заклинания под бубен...
VB>> Программа должна работать БЕЗ них... И работает...
AK> Ну, если брать использование радиуса чисто под фиду, то да. Но если
AK> использовать его для других задач, то проявляется явно недостаточная
AK> скорость и дикий жор процессора из коробки.

Во-о-о-от!.. Начинаем раскрывать тему потребления по-тихо-о-оньку!...
Давай-давай!.. Продолжай!.. Этим и "проблема" решится до кучи...
/Д.Войтюк ржёт уже за углом в кулачок :-D/

AK>>> Во-первых, стабильность работы (целостность данных) радиуса и
AK>>> компании не должна зависить от скорости работы сети.
VB>> Именно так и есть...
AK> А вот фиг вам. Если ставить галку в настройках протокола Binkp
AK> "требовать шифрование", то у меня даже версия отцов-основателей
AK> (2005г.) уходит в затык при попытке установить сессию. Если параметры
AK> реестра поменять на обоих сторонах, то сессии начинают успешно
AK> устанавливаться. Что я делаю не так? (Но мне это пока что не
AK> актуально, и поэтому я повторно не проверял после своих последних
AK> изменений)

ТЫ?.. Конкретно ТЫ?..
Меняешь настройки системы, которые никому менять не надо, например...

AK>>> Я так понимаю.
AK>>> Если косяк есть, логично его исправить если есть возможность.
VB>> Нет косяка...
AK> И снова фиг вам :-) Нашел и исправил. Радиус думал что данные могут
AK> приходить по чуть-ть, и что он работает быстрей поступления данных. А
AK> они неожиданно приходили в процессе его работы.. Уже прокачал
AK> несколько раз по 100тыс файлов на криптованной сессии, ни единого
AK> разрыва! (с)

Да и отлично!!!
Ты какого-то "сферического коня в вакууме" подсовываешь, от которого никому ни жарко, ни холодно...
Я всякой binkP-ой пользуюсь с 96-го года, т.е. почти 20 лет... На *rgus перешёл только потому, что держать и воспитывать одновременно tmail и binkd стало стрёмно... Да и люблю я помогать в разработке хорошим друзьям...

AK>>> Кого-нибудь дамп трафика интересует?
VB>> Да... ФСБ...
AK> Как скажешь.

Ну, главное, чтобы они ничего не придумали, глядя на них!.. :=D

Arrivederci, Korotkov!..
> ------------------------------------------------------------
Windows 7 Ultimate x86 [version 6.1.7601] Service Pack 1
Taurus v.5.114.2013.19/Winter/FastMM 4.991/DEBUG
--- System uptime is: 4 day(s) 14:09:29.607 (max. - 27 day(s) 6:38:31.123)
Ответить с цитированием
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 14:21. Часовой пояс GMT +4.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2022, vBulletin Solutions, Inc. Перевод: zCarot