информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяСтрашный баг в WindowsSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[RC5] Канэшно можно ;-) 10.07.03 11:29  Число просмотров: 1662
Автор: NetGhost Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Хай! Можно ли заставить dnetc пользоваться бОльшими
> порциями блоков, нежели по 24 за раз? Если можно, то как?
> Весь конфиг перерыл и не нашёл :((

[rc5-72]
fetch-time-threshold=72

Это закачивать блоки на 72 часа работы. Меняется по желанию :)
А можно так:

[rc5-72]
fetch-workunit-threshold=1000

закачивать 1000 блоков...
ИМХО первый вариант более предпочтителен.
<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 блоков...
ИМХО первый вариант более предпочтителен.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach