> А где можно взять полное описание конфига? Шляпу не съем, что его вообще нет, но мне такого не попадалось.
dnetc -help - это полное описание ключей при запуске. Больше ничего полного я не видел.
Лучше пиши, что конкретно нужно поднастроить, тут всегда помогут.
Можно сделать так...11.07.03 09:13 Автор: NetGhost Статус: Незарегистрированный пользователь Отредактировано 11.07.03 09:18 Количество правок: 1
> > А где можно взять полное описание конфига? > Шляпу не съем, что его вообще нет, но мне такого не > попадалось. > dnetc -help - это полное описание ключей при запуске. > Больше ничего полного я не видел. > Лучше пиши, что конкретно нужно поднастроить, тут всегда > помогут.
dnetc -config - изменяешь какой-нить пункт, сохраняешь и смотришь в конфиге что получилось.
У тебя выставлен такой режим (2), при котором чекается только выходной буфер на предмет того, что он НЕ ПУСТ. Т.е. у тебя каждые 10 секунд проверяется, не пополнился ли buff-out, и как только определяется, что этот буфер не пуст, происходит flush - сливание твоих блоков на сервер/в файл.
Зачем так часто - каждые 10 секунд чекать? По умолчанию ведь клиент и так чекает любое изменение буферов, и не чаще, чем два раза в минуту.
Я понимаю, такой режим нужно использовать, и с интервалом, меньшим значения по умолчанию, только на машине, кормящей другие машины в сети, и ставить значение не 2, а 1, т.е.:
frequent-threshold-checks=1
это проверка входного buff-in буфера на предмет того, что он НЕ ПОЛОН.
Значение 3 объединяет 1и 2, и используетcя только для dial-up.
> checkpoint-filename=checkp.hlz
Этот параметр, конечно, полезен при частых пропаданиях электричества и зависаниях, но специалисты с distributed.net говорят, что наличие этого параметра уменьшает производительность клиента.
> restart-on-config-file-change=yes
Так же, как и наличие вот этого параметра.
Я прочитал об этом в мэйллистах на distributed.net.
> > frequent-threshold-checks=2 > > threshold-check-interval=0:10 > Зачем так часто - каждые 10 секунд чекать? По умолчанию
> > checkpoint-filename=checkp.hlz > Этот параметр, конечно, полезен при частых пропаданиях > электричества и зависаниях, но специалисты с > distributed.net говорят, что наличие этого параметра > уменьшает производительность клиента.
> > restart-on-config-file-change=yes > Так же, как и наличие вот этого параметра. > Я прочитал об этом в мэйллистах на distributed.net.
> > [buffers] > > frequent-threshold-checks=2 > > threshold-check-interval=0:10 > У тебя выставлен такой режим (2), при котором чекается > только выходной буфер на предмет того, что он НЕ ПУСТ. Т.е.
чтобы не залеживалось. это также провоцирует обмен не дожидаясь полного опустошения входящего буфера - как это легкомысленно по дефолту реализовано в последних версиях коровы. (помню версию от 1999 года, где можно было задать обмен раз в N блоков, где N > 1 и N < размера входного буфера). раздражает также и неумение обмениваться дуплексно или пачками не дожидаясь подтверждения по каждому блоку прежде чем запрашивать/отсылать следующий - как это сделано в perproxy.
> у тебя каждые 10 секунд проверяется, не пополнился ли > buff-out, и как только определяется, что этот буфер не > пуст, происходит flush - сливание твоих блоков на сервер/в файл.
происходит полный апдейт, причем начинается именно с buff-in.
> Зачем так часто - каждые 10 секунд чекать? По умолчанию > ведь клиент и так чекает любое изменение буферов, и не > чаще, чем два раза в минуту.
может появиться диал-ап ненадолго, либо нужно возобновлять прерванную сессию обмена <пока все полностью не прокачано> либо нужно побольше долбиться чтобы увеличить шансы успевать все обменивать на перегруженном соединении.
> Я понимаю, такой режим нужно использовать, и с интервалом, > меньшим значения по умолчанию, только на машине, кормящей > другие машины в сети, и ставить значение не 2, а 1, т.е.: > frequent-threshold-checks=1 > это проверка входного buff-in буфера на предмет того, что он НЕ ПОЛОН.
на некормящей своими буферами других корове опции 1-3 эквивалентны (buff-in не полон = buff-out не пуст = и то и то одновременно)
> Значение 3 объединяет 1и 2, и используетcя только для dial-up.
ну и кто тебе сказал такую ерунду?
> > checkpoint-filename=checkp.hlz > Этот параметр, конечно, полезен при частых пропаданиях > электричества и зависаниях, но специалисты с > distributed.net говорят, что наличие этого параметра > уменьшает производительность клиента. > > restart-on-config-file-change=yes > Так же, как и наличие вот этого параметра.
это интуитивно понятно. открытый в июле люк в машине тоже ухудшает аэродинамику и следовательно увеличивает расход денег на бензин.
> Я прочитал об этом в мэйллистах на distributed.net.
so learn, learn, and learn ;)
[RC5] видимо ты сам даже не пробовал так настраивать... :(22.07.03 02:35 Автор: jammer <alex naumov> Статус: Elderman
> > > frequent-threshold-checks=2 > > У тебя выставлен такой режим (2), при котором чекается > > только выходной буфер на предмет того, что он НЕ ПУСТ.
хм... пробовал на одной из машин выставить =0. и тут же выяснилось что корова начинает циклить проекты: rc5 и ogr по очереди. часов 6 бедный соплерон 333 отжевывал часть видимо не самого мелкого блока ogr. мать перемать думаю :) вобщем возникла параноидальная мысль, что ты меня в подкомандной статистике по rc5 обогнать хочешь :))) извини братан я за статистикой реально слежу...
таким образом, на выделенной линии связи (перпрокси на том же компе, в локальной сети или на стабильной выделенке) получаем что 1=2=3. =0 - для желающих распыляться в нужном соотношении (размеры буферов). =4 - для максимальной экономии трафика.
мои коровы работают с =2, т.к. мне нужно именно это - чтобы блоки не залеживались, видеть реальную скорость и оперативно отслеживать возникающие где-то проблемы.
Ещё на проекте RC5-64 я экспериментировал с DIAL-UP'ом и этими параметрами.
Никогда не занимался проектом OGR, поэтому не знаю, как будут дружить они оба при включении этих параметров.
Ещё раз замечу, что, согласно докам distributed.net, дополнительную проверку буферов нужно организовывать только на машинах, кормящих других по сети, поскольку никто не знает, в какой момент какая-нибудь из кормящихся машин сожрёт последний блок из общего буфера.
> Ещё на проекте RC5-64 я экспериментировал с DIAL-UP'ом и > этими параметрами. > Никогда не занимался проектом OGR, поэтому не знаю, как > будут дружить они оба при включении этих параметров.
полностью выключать ОГР нехорошо, есть вероятность что автопилотная машина станет бесполезной, если внезапно кончится рц5-72. а кончится он может на любом блоке в любой момент.
> Ещё раз замечу, что, согласно докам distributed.net, > дополнительную проверку буферов нужно организовывать только > на машинах, кормящих других по сети, поскольку никто не > знает, в какой момент какая-нибудь из кормящихся машин > сожрёт последний блок из общего буфера.
это все понятно и не раз отлаживалось в реальных сетях, но других вариантов жизнеспособных конфигов не вижу.
> полностью выключать ОГР нехорошо, есть вероятность что > автопилотная машина станет бесполезной, если внезапно > кончится рц5-72. а кончится он может на любом блоке в любой > момент.
...ты о чем, вообще? Я тоже не совсем трезв, но не на столько же, млин.
Как это кончится RC5-72??? Когда? Назови точную (плюс-минус сто лет) дату. Да ты в курсе, вообще, что randomize'ных OGR'ов не бывает?
Жду пояснений...
> > полностью выключать ОГР нехорошо, есть вероятность что > > автопилотная машина станет бесполезной, если внезапно > > кончится рц5-72. а кончится он может на любом блоке в любой > > момент. > > ...ты о чем, вообще? Я тоже не совсем трезв, но не на > столько же, млин. > Как это кончится RC5-72??? Когда? Назови точную (плюс-минус сто лет) дату.
читай внимательнее. кончиться rc5-72 может, как и rc5-64, в любой момент до достижения окончания кейспэйса. при условии что алгоритм обсчета без ошибки ;)
> Да ты в курсе, вообще, что randomize'ных OGR'ов не бывает?
конечно, поэтому надо их запасать. к счастью, они черезчур трудоемкие, чтобы их запасание было заметной проблемой :)
> > полностью выключать ОГР нехорошо, есть вероятность что > > автопилотная машина станет бесполезной, если внезапно > > кончится рц5-72. а кончится он может на любом блоке в > любой > > момент. > > ...ты о чем, вообще? Я тоже не совсем трезв, но не на > столько же, млин. > Как это кончится RC5-72??? Когда? Назови точную (плюс-минус > сто лет) дату. Вообще-то jammer прав, РЦ5-72 может закончится в любой момент. Смысл проекта в том чтобы найти правильный ключик. А ключик этот может быть в любом блоке.
> > ...ты о чем, вообще? Я тоже не совсем трезв, но не на > > столько же, млин. > > Как это кончится RC5-72??? Когда? Назови точную > (плюс-минус > > сто лет) дату. > Вообще-то jammer прав, РЦ5-72 может закончится в любой > момент. Смысл проекта в том чтобы найти правильный ключик. > А ключик этот может быть в любом блоке. Может то он может, но пока вероятность этого сравнима с вероятностью падения на Землю крупного астероида. Если быть точным, 0.000179%.
[RC5] поздравьте меня с 50 местом в BugTraq !26.07.03 03:08 Автор: jammer <alex naumov> Статус: Elderman
> > А ключик этот может быть в любом блоке. > Может то он может, но пока вероятность этого сравнима с > вероятностью падения на Землю крупного астероида. Если быть > точным, 0.000179%.
вот ввиду того, что она больше нуля, мне не рекомендовали полностью отключать ОГР, что было ощутимо полезно в момент окончания rc5-64. вспомним, что тогда тоже никто не знал, когда именно он закончится.
> на некормящей своими буферами других корове опции 1-3 > эквивалентны (buff-in не полон = buff-out не пуст = и то и > то одновременно) > > > Значение 3 объединяет 1и 2, и используетcя только для > dial-up. > > ну и кто тебе сказал такую ерунду?
Режим 3 цитирую: "Implied if "Dialup detection options" are enabled".
> Хай! Можно ли заставить dnetc пользоваться бОльшими > порциями блоков, нежели по 24 за раз? Если можно, то как? > Весь конфиг перерыл и не нашёл :(( По умолчанию в конфиге минимум параметров. Все остальные задаются по умолчанию. Чтобы узнать, как те или иные регулировки сделать через конфиг, нужно запустить dnetc - config, через систему меню выставить нужные параметры и режимы, а потом посмотреть, как это отразилось в dnetc.ini.
[RC5] Канэшно можно ;-)10.07.03 11:29 Автор: NetGhost Статус: Незарегистрированный пользователь
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
