Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | | |
[RC5] пробовал, но 23.07.03 23:18 Число просмотров: 1772
Автор: jammer <alex naumov> Статус: Elderman
|
> Ещё на проекте RC5-64 я экспериментировал с DIAL-UP'ом и > этими параметрами. > Никогда не занимался проектом OGR, поэтому не знаю, как > будут дружить они оба при включении этих параметров.
полностью выключать ОГР нехорошо, есть вероятность что автопилотная машина станет бесполезной, если внезапно кончится рц5-72. а кончится он может на любом блоке в любой момент.
> Ещё раз замечу, что, согласно докам distributed.net, > дополнительную проверку буферов нужно организовывать только > на машинах, кормящих других по сети, поскольку никто не > знает, в какой момент какая-нибудь из кормящихся машин > сожрёт последний блок из общего буфера.
это все понятно и не раз отлаживалось в реальных сетях, но других вариантов жизнеспособных конфигов не вижу.
|
<dnet>
|
[RC5] Хай! Можно ли заставить dnetc пользоваться бОльшими порциями блоков... 10.07.03 10:55
Автор: _Andrew_ Статус: Незарегистрированный пользователь
|
Хай! Можно ли заставить dnetc пользоваться бОльшими порциями блоков, нежели по 24 за раз? Если можно, то как?
Весь конфиг перерыл и не нашёл :((
|
|
Big thanx!... 10.07.03 17:01
Автор: _Andrew_ Статус: Незарегистрированный пользователь
|
А где можно взять полное описание конфига?
|
| |
Описание конфига - врядли. 10.07.03 23:14
Автор: Kost <Пробки Москвы> Статус: Elderman
|
> А где можно взять полное описание конфига? Шляпу не съем, что его вообще нет, но мне такого не попадалось.
dnetc -help - это полное описание ключей при запуске. Больше ничего полного я не видел.
Лучше пиши, что конкретно нужно поднастроить, тут всегда помогут.
|
| | |
Можно сделать так... 11.07.03 09:13
Автор: NetGhost Статус: Незарегистрированный пользователь Отредактировано 11.07.03 09:18 Количество правок: 1
|
> > А где можно взять полное описание конфига? > Шляпу не съем, что его вообще нет, но мне такого не > попадалось. > dnetc -help - это полное описание ключей при запуске. > Больше ничего полного я не видел. > Лучше пиши, что конкретно нужно поднастроить, тут всегда > помогут.
dnetc -config - изменяешь какой-нить пункт, сохраняешь и смотришь в конфиге что получилось.
|
| | | |
[RC5] dnetc -config / F3 .ini 11.07.03 10:36
Автор: jammer <alex naumov> Статус: Elderman
|
> dnetc -config - изменяешь какой-нить пункт, сохраняешь и > смотришь в конфиге что получилось.
Костя об этом уже писал.
если все настройки сбить с дефолта, она все пропишет в .ini и все будет видно - кроме взаимоисключающих настроек, кажется есть такие.
но обычно имхо достаточно менять только это (может еще хттп-прокси вписать или настроить отслеживалку dial-up):
[parameters]
id=jammer@nm.ru
[buffers]
frequent-threshold-checks=2
threshold-check-interval=0:10
checkpoint-filename=checkp.hlz
[misc]
project-priority=RC5-72,OGR
[triggers]
pause-watch-plist=taskmgr
restart-on-config-file-change=yes
[display]
detached=yes
[rc5-72]
fetch-workunit-threshold=200
[ogr]
fetch-workunit-threshold=1
[networking]
autofindkeyserver=no
keyserver=rc5.stel.ru
;keyserver=mordor
[logging]
log-file-limit=100
log-file=idle.log
log-file-type=fifo
|
| | | | |
[RC5] dnetc -config 11.07.03 19:31
Автор: Неизв. Статус: Незарегистрированный пользователь
|
> [buffers] > frequent-threshold-checks=2 > threshold-check-interval=0:10
У тебя выставлен такой режим (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.
С уважением,
Неизвестный Доброжелатель
|
| | | | | |
[RC5] dnetc -config 22.07.03 04:23
Автор: jammer <alex naumov> Статус: Elderman
|
> > frequent-threshold-checks=2 > > threshold-check-interval=0:10 > Зачем так часто - каждые 10 секунд чекать? По умолчанию
> > checkpoint-filename=checkp.hlz > Этот параметр, конечно, полезен при частых пропаданиях > электричества и зависаниях, но специалисты с > distributed.net говорят, что наличие этого параметра > уменьшает производительность клиента.
> > restart-on-config-file-change=yes > Так же, как и наличие вот этого параметра. > Я прочитал об этом в мэйллистах на distributed.net.
да уж, круто. увы, ничего не меняется...
2003-07-21 23:59:48,rc5-72 r=1500/1500, d=0/1, 6.8 Mkeys/sec, tot=341/341 blocks
правда, я снял свой крохотный разгон с АХР, ибо он стал пугающе греться в жару. виснуть хотя и не вис.
|
| | | | | |
[RC5] learn, learn, and learn ;) 12.07.03 23:48
Автор: jammer <alex naumov> Статус: Elderman
|
> > [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] пробовал, но 23.07.03 15:31
Автор: Неизв. Статус: Незарегистрированный пользователь
|
Ещё на проекте RC5-64 я экспериментировал с DIAL-UP'ом и этими параметрами.
Никогда не занимался проектом OGR, поэтому не знаю, как будут дружить они оба при включении этих параметров.
Ещё раз замечу, что, согласно докам distributed.net, дополнительную проверку буферов нужно организовывать только на машинах, кормящих других по сети, поскольку никто не знает, в какой момент какая-нибудь из кормящихся машин сожрёт последний блок из общего буфера.
|
| | | | | | | | |
[RC5] пробовал, но 23.07.03 23:18
Автор: jammer <alex naumov> Статус: Elderman
|
> Ещё на проекте RC5-64 я экспериментировал с DIAL-UP'ом и > этими параметрами. > Никогда не занимался проектом OGR, поэтому не знаю, как > будут дружить они оба при включении этих параметров.
полностью выключать ОГР нехорошо, есть вероятность что автопилотная машина станет бесполезной, если внезапно кончится рц5-72. а кончится он может на любом блоке в любой момент.
> Ещё раз замечу, что, согласно докам distributed.net, > дополнительную проверку буферов нужно организовывать только > на машинах, кормящих других по сети, поскольку никто не > знает, в какой момент какая-нибудь из кормящихся машин > сожрёт последний блок из общего буфера.
это все понятно и не раз отлаживалось в реальных сетях, но других вариантов жизнеспособных конфигов не вижу.
|
| | | | | | | | | |
[RC5] ...нельзя выключать OGR?! 24.07.03 15:18
Автор: ghostick <Co$TicK's Gho$T> Статус: Member
|
> полностью выключать ОГР нехорошо, есть вероятность что > автопилотная машина станет бесполезной, если внезапно > кончится рц5-72. а кончится он может на любом блоке в любой > момент.
...ты о чем, вообще? Я тоже не совсем трезв, но не на столько же, млин.
Как это кончится RC5-72??? Когда? Назови точную (плюс-минус сто лет) дату. Да ты в курсе, вообще, что randomize'ных OGR'ов не бывает?
Жду пояснений...
|
| | | | | | | | | | |
[RC5] ...нельзя выключать OGR?! 26.07.03 02:02
Автор: jammer <alex naumov> Статус: Elderman
|
> > полностью выключать ОГР нехорошо, есть вероятность что > > автопилотная машина станет бесполезной, если внезапно > > кончится рц5-72. а кончится он может на любом блоке в любой > > момент. > > ...ты о чем, вообще? Я тоже не совсем трезв, но не на > столько же, млин. > Как это кончится RC5-72??? Когда? Назови точную (плюс-минус сто лет) дату.
читай внимательнее. кончиться rc5-72 может, как и rc5-64, в любой момент до достижения окончания кейспэйса. при условии что алгоритм обсчета без ошибки ;)
> Да ты в курсе, вообще, что randomize'ных OGR'ов не бывает?
конечно, поэтому надо их запасать. к счастью, они черезчур трудоемкие, чтобы их запасание было заметной проблемой :)
|
| | | | | | | | | | |
[RC5] ...нельзя выключать OGR?! 25.07.03 07:23
Автор: NetGhost Статус: Незарегистрированный пользователь
|
> > полностью выключать ОГР нехорошо, есть вероятность что > > автопилотная машина станет бесполезной, если внезапно > > кончится рц5-72. а кончится он может на любом блоке в > любой > > момент. > > ...ты о чем, вообще? Я тоже не совсем трезв, но не на > столько же, млин. > Как это кончится RC5-72??? Когда? Назови точную (плюс-минус > сто лет) дату. Вообще-то jammer прав, РЦ5-72 может закончится в любой момент. Смысл проекта в том чтобы найти правильный ключик. А ключик этот может быть в любом блоке.
|
| | | | | | | | | | | |
[RC5] ...нельзя выключать OGR?! 25.07.03 08:17
Автор: Kost <Пробки Москвы> Статус: Elderman
|
> > ...ты о чем, вообще? Я тоже не совсем трезв, но не на > > столько же, млин. > > Как это кончится RC5-72??? Когда? Назови точную > (плюс-минус > > сто лет) дату. > Вообще-то jammer прав, РЦ5-72 может закончится в любой > момент. Смысл проекта в том чтобы найти правильный ключик. > А ключик этот может быть в любом блоке. Может то он может, но пока вероятность этого сравнима с вероятностью падения на Землю крупного астероида. Если быть точным, 0.000179%.
|
| | | | | | | | | | | | |
[RC5] поздравьте меня с 50 местом в BugTraq ! 26.07.03 03:08
Автор: jammer <alex naumov> Статус: Elderman
|
> > А ключик этот может быть в любом блоке. > Может то он может, но пока вероятность этого сравнима с > вероятностью падения на Землю крупного астероида. Если быть > точным, 0.000179%.
вот ввиду того, что она больше нуля, мне не рекомендовали полностью отключать ОГР, что было ощутимо полезно в момент окончания rc5-64. вспомним, что тогда тоже никто не знал, когда именно он закончится.
|
| | | | | | |
[RC5] learn, learn, and learn ;) 17.07.03 13:04
Автор: Роб Статус: Незарегистрированный пользователь
|
> на некормящей своими буферами других корове опции 1-3 > эквивалентны (buff-in не полон = buff-out не пуст = и то и > то одновременно) > > > Значение 3 объединяет 1и 2, и используетcя только для > dial-up. > > ну и кто тебе сказал такую ерунду?
Режим 3 цитирую: "Implied if "Dialup detection options" are enabled".
|
| | | | | | | |
[RC5] learn, learn, and learn ;) 19.07.03 18:29
Автор: jammer <alex naumov> Статус: Elderman
|
> Режим 3 цитирую: "Implied if "Dialup detection options" are enabled".
тем не менее, работает и без этого. даже на запрещенном нетворкинге.
|
|
[RC5] Насчет конфига... 10.07.03 11:57
Автор: Kost <Пробки Москвы> Статус: Elderman
|
> Хай! Можно ли заставить dnetc пользоваться бОльшими > порциями блоков, нежели по 24 за раз? Если можно, то как? > Весь конфиг перерыл и не нашёл :(( По умолчанию в конфиге минимум параметров. Все остальные задаются по умолчанию. Чтобы узнать, как те или иные регулировки сделать через конфиг, нужно запустить dnetc - config, через систему меню выставить нужные параметры и режимы, а потом посмотреть, как это отразилось в dnetc.ini.
|
|
[RC5] Канэшно можно ;-) 10.07.03 11:29
Автор: NetGhost Статус: Незарегистрированный пользователь
|
> Хай! Можно ли заставить dnetc пользоваться бОльшими > порциями блоков, нежели по 24 за раз? Если можно, то как? > Весь конфиг перерыл и не нашёл :((
[rc5-72]
fetch-time-threshold=72
Это закачивать блоки на 72 часа работы. Меняется по желанию :)
А можно так:
[rc5-72]
fetch-workunit-threshold=1000
закачивать 1000 блоков...
ИМХО первый вариант более предпочтителен.
|
|
|