информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Spanning Tree Protocol: недокументированное применениеГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
когда показывается в виде 30.07.07 12:55  Число просмотров: 2526
Автор: michaek Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Клиент ведь показывает актуальную скорость расчета,
> складывая скорость потоков a и b? Просто у меня получается
> при одном потоке показывает скорость 26 800, а на двух
> потоках всего 18 500! Или клиент имеет ввиду 18 500 для
> каждого потока (что вряд ли)? Как лучше тогда считать?

когда показывается в виде
OGR-P2 #a: Completed 25/2-16-33-4-28-12 (14.35 stats units)
0.00:06:15.06 - [38,273,554 nodes/s]
то это скорость обсчета этой нити (а)

если же пишется нечто вроде
OGR-P2: Summary: 1592 packets (42699.62 stats units)
1.15:08:34.72 - [301.65 Mnodes/s]
то это общая скорость обсчета в клиенте

HT лучше вообще не использовать, если же отключать не хочется, то ставить число нитей в max-threads равным числу физических процессоров (ядер)
<dnet>
[OGR] Скоро будет миллиард OGR 19.07.07 09:18  
Автор: hazkep@mail.ru Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Я присоединился к расчетам OGR. Будет около 15 компов нормальных. Немного, но все же. :)
И это 'скоро' наступило! 26.07.07 18:27  
Автор: ghostick <Co$TicK's Gho$T> Статус: Member
<"чистая" ссылка>
И это 'скоро' наступило!
С чем всех и поздравляю!
Досчитали!
[OGR] Ага. А сегодня еще и 2 с лишним миллиона гнод слили. :) 27.07.07 10:43  
Автор: hazkep@mail.ru Статус: Незарегистрированный пользователь
<"чистая" ссылка>
+1 =) поздравляю всех ) 26.07.07 18:49  
Автор: !mm <Ivan Ch.> Статус: Elderman
<"чистая" ссылка>
15 компов это примерно 20 000 гнод в день :) совсем не лишне... 21.07.07 20:02  
Автор: i1 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
15 компов это примерно 20 000 гнод в день :) совсем не лишне надо сказать :)
а миллиард думаю будет в среду четверг, собираюсь поить пивом друзей которым клиента поставил :)
Думаю будет даже больше чем 20 000, потому что уже 13 000... 21.07.07 20:25  
Автор: hazkep Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Думаю будет даже больше чем 20 000, потому что уже 13 000 выдает, я еще только на половину компов поставил. Только вот почему-то проблемы на Core 2 Duo и P 4 с HyperThreading - тормоза появляются и юзеры жалуются, приходится ограничивать процессорное время коровки. На одноядерниках все в порядке и без ограничений.

P.S. Конечно, сплоченности команде Bugtraq не хватает, мне кажется раньше с этим лучше было, народу на форуме тоже мало. Такое ощущение, что как минимум половина клиентов неконтролируемых, установленных в прошлые, лучшие времена:)
Просто в конфиге пропиши один поток принудительно и все... 28.07.07 21:13  
Автор: SergNe0 <Sergey> Статус: Member
<"чистая" ссылка>
> Думаю будет даже больше чем 20 000, потому что уже 13 000
> выдает, я еще только на половину компов поставил. Только
> вот почему-то проблемы на Core 2 Duo и P 4 с HyperThreading
> - тормоза появляются и юзеры жалуются, приходится
> ограничивать процессорное время коровки.

Просто в конфиге пропиши один поток принудительно и все будет ок.
[processor-usage]
priority=0
max-threads=1
Тогда медленне считать будет :) Может так и сделаю 29.07.07 11:01  
Автор: hazkep Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Ну конечно медленней будет:) 29.07.07 23:37  
Автор: SergNe0 <Sergey> Статус: Member
<"чистая" ссылка>
Ну конечно медленней будет:)
Главное не будет комп тормозить и раздражать всяких юзеров сидящих за ним, не давая о себе знать, в нашем деле главное скрытность.
компы с HT в два потока все равно не намного быстрее считают.. хотя я могу ошибаться ) 30.07.07 09:21  
Автор: !mm <Ivan Ch.> Статус: Elderman
<"чистая" ссылка>
[OGR] Пожалуй, ты прав 30.07.07 11:21  
Автор: hazkep Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Я проверил. Практически одинаково считают, что в один поток, что в два.
[OGR] Что то я не понял фишку со скоростью 30.07.07 11:31  
Автор: hazkep Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Клиент ведь показывает актуальную скорость расчета, складывая скорость потоков a и b? Просто у меня получается при одном потоке показывает скорость 26 800, а на двух потоках всего 18 500! Или клиент имеет ввиду 18 500 для каждого потока (что вряд ли)? Как лучше тогда считать?
когда показывается в виде 30.07.07 12:55  
Автор: michaek Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Клиент ведь показывает актуальную скорость расчета,
> складывая скорость потоков a и b? Просто у меня получается
> при одном потоке показывает скорость 26 800, а на двух
> потоках всего 18 500! Или клиент имеет ввиду 18 500 для
> каждого потока (что вряд ли)? Как лучше тогда считать?

когда показывается в виде
OGR-P2 #a: Completed 25/2-16-33-4-28-12 (14.35 stats units)
0.00:06:15.06 - [38,273,554 nodes/s]
то это скорость обсчета этой нити (а)

если же пишется нечто вроде
OGR-P2: Summary: 1592 packets (42699.62 stats units)
1.15:08:34.72 - [301.65 Mnodes/s]
то это общая скорость обсчета в клиенте

HT лучше вообще не использовать, если же отключать не хочется, то ставить число нитей в max-threads равным числу физических процессоров (ядер)
[OGR] Я имел ввиду другое 30.07.07 13:23  
Автор: hazkep Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Реальную скорость которую показывает клиент в реальном времени.
Сейчас дома проверил, получается что с HT, когда используется два потока - считает медленее. 30.07.07 13:27  
Автор: hazkep Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Угу, и дохнут потихонечку... 22.07.07 12:10  
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 22.07.07 12:10  Количество правок: 1
<"чистая" ссылка>
> P.S. Конечно, сплоченности команде Bugtraq не хватает, мне
> кажется раньше с этим лучше было, народу на форуме тоже
> мало. Такое ощущение, что как минимум половина клиентов
> неконтролируемых, установленных в прошлые, лучшие времена:)
Угу, и дохнут потихонечку...
насчет HT и Core 2 Duo - хз... 21.07.07 21:26  
Автор: i1 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
насчет HT и Core 2 Duo - хз...
у меня на работе на моей двухядерной машине все нормально - работаю и играю со включенным без тормозов...
насчет ЗЫ - по мне так нормально :)
Core 2 Duo в ограх вообще великлепны. если на RC5-72 у них... 30.07.07 14:48  
Автор: aLEXt <Alex Trusty> Статус: Member
Отредактировано 03.08.07 14:48  Количество правок: 2
<"чистая" ссылка>
> насчет HT и Core 2 Duo - хз...
> у меня на работе на моей двухядерной машине все нормально -
> работаю и играю со включенным без тормозов...
> насчет ЗЫ - по мне так нормально :)
Core 2 Duo в ограх вообще великолепны. если на RC5-72 у них IPC менше, чем у атлонов, то на ограх больше. Соответственно равночастотный Core проиграет атлону в RC5, но прилично уделает в ORG-25:
http://lug.cbx.ru/forum/viewtopic.php?pid=610#p610
[OGR] На моем Core 2 Duo 3 ГГц OGR выдает около 90 000 000 nodes/sec 30.07.07 19:31  
Автор: hazkep Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Ничего удивительного, я же приводил результаты для одного... 03.08.07 14:47  
Автор: aLEXt <Alex Trusty> Статус: Member
<"чистая" ссылка>
Ничего удивительного, я же приводил результаты для одного ядра, 1800MHz
1  |  2 >>  »  




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


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