информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеПортрет посетителяСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[RC5] а смысл? 11.02.09 15:53  Число просмотров: 2018
Автор: panam Статус: Незарегистрированный пользователь
<"чистая" ссылка>
В чем смысл больших блоков? в размере? так прокся на ~ 60к блоков в сутки оперирует объемом 10 мегабайт.

А я только сейчас вкурил фичу авторегулирования объема входного буфера в 343 версии - реально работает, реагирует на скорость работы клиентов :)
<dnet>
Командная прокся 11.02.09 11:44  
Автор: Ritual Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Есть смысл обновится до 347 релиза имхо. Во-первых, там добавлена поддержка крупных блоков для RC5, а во-вторых, в связи со скорым запуском OGR-27:

Add support for larger block sizes in rc5-72 (#3918)

Add logic to not distribute OGR-NG blocks to clients earlier than
build 509 or proxies earlier than build 346 once OGR-27 begins.
[RC5] Командная прокся 16.02.09 16:44  
Автор: panam Статус: Незарегистрированный пользователь
<"чистая" ссылка>
обновился на головной проксе до 347 билда.
появились 2 новых файлика pprc5in.rc5 и pprc5out.rc5 в добавок к привычным ppready.r72 и ppdone.r72.
но используются старые буфера.
[RC5] а смысл? 11.02.09 15:53  
Автор: panam Статус: Незарегистрированный пользователь
<"чистая" ссылка>
В чем смысл больших блоков? в размере? так прокся на ~ 60к блоков в сутки оперирует объемом 10 мегабайт.

А я только сейчас вкурил фичу авторегулирования объема входного буфера в 343 версии - реально работает, реагирует на скорость работы клиентов :)
Как я понимаю, это предназначено для супербыстромолотящих... 11.02.09 17:17  
Автор: Ritual Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> В чем смысл больших блоков? в размере? так прокся на ~ 60к
> блоков в сутки оперирует объемом 10 мегабайт.

Как я понимаю, это предназначено для супербыстромолотящих CUDA клиентов. Они за пару-тройку часов тысячу обычных блоков обсчитывают.
[RC5] не сказал бы что примерно 3гигакея 11.02.09 20:36  
Автор: panam Статус: Незарегистрированный пользователь
<"чистая" ссылка>
сильно грузят 1 проксю на стареньких атлонах мп в количестве 2х штук.
А машина из трех 9800GTX+ тысячу считает за 58 минут.
[RC5] 12.02.09 09:59  
Автор: stream <Roman Trunov> Статус: Member
<"чистая" ссылка>
> не сказал бы что примерно 3гигакея
> сильно грузят 1 проксю на стареньких атлонах мп в
> количестве 2х штук.

Это не для проксей было сделано, а для клиентов. На быстромолотящих видеокартах, где обычный RC5-блок считается всего несколько секунд, становится заметным время чтения/записи блока из буферов - видеокарта простаивает, общая скорость падает. Поэтому сделали блоки большего размера, чтобы можно было пожевать подольше.

А обновляться с началом OGR-27 все равно придется. Т.е максимум через пару недель в любом случае.
[RC5]типа вот этого: 12.02.09 12:11  
Автор: panam Статус: Незарегистрированный пользователь
<"чистая" ссылка>
попытка прогнать тест на системе из 3-х 9800gx2:

[Feb 12 08:16:33 UTC] Automatic processor detection found 6 processors.
[Feb 12 08:16:33 UTC] Loading crunchers with work...
[Feb 12 08:16:33 UTC] Connected to euro.v29.distributed.net:2064...
[Feb 12 08:16:33 UTC] The keyserver says: "OGR-NG.. Sounds like a new Star
Trek series.. (bang)"
[Feb 12 08:16:33 UTC] Retrieved project state data from server. (cached)
[Feb 12 08:16:37 UTC] RC5-72: Retrieved stats unit 1010 of 1010 (100.00%)
[Feb 12 08:16:37 UTC] Connection closed.
[Feb 12 08:16:37 UTC] Automatic processor type detection found
a GeForce 9800 GX2 (16 MPs) processor.
[Feb 12 08:16:37 UTC] RC5-72: using core #0 (CUDA 1-pipe 64-thd).
[Feb 12 08:16:37 UTC] RC5-72 #a: Loaded CB:F75D1EF2:00000000:37*2^32
[Feb 12 08:16:37 UTC] RC5-72 #b: Loaded CB:F75D1FBC:00000000:64*2^32
[Feb 12 08:16:37 UTC] RC5-72 #c: Loaded CB:F8E2EFEA:00000000:45*2^32
[Feb 12 08:16:37 UTC] RC5-72 #d: Loaded CB:F9D41EE0:00000000:55*2^32
[Feb 12 08:16:37 UTC] RC5-72 #e: Loaded CB:FAB0EAD9:00000000:62*2^32
[Feb 12 08:16:37 UTC] RC5-72 #f: Loaded CB:FAB0F1E6:00000000:49*2^32
[Feb 12 08:16:37 UTC] RC5-72: 11 packets (698.00 stats units) remain in
buff-in.r72
[Feb 12 08:16:37 UTC] RC5-72: 0 packets are in buff-out.r72
[Feb 12 08:16:37 UTC] 6 crunchers ('a'-'f') have been started.

-cpuinfo, -bench, - test, -stress будут чуть позже.


ЗЫ а примерно насколько (ну хоть в процентах) блоки 64*2^32 будут быстрее 32*2^32 считаться?
_блоки_ считаются с одинаковой скоростью. уменьшается время,... 12.02.09 12:41  
Автор: stream <Roman Trunov> Статус: Member
<"чистая" ссылка>
> ЗЫ а примерно насколько (ну хоть в процентах) блоки 64*2^32
> будут быстрее 32*2^32 считаться?

_блоки_ считаются с одинаковой скоростью. уменьшается время, теряемое на их перезагрузку в кранчерах. т.е. ядро по-прежнему сообщит те же самые NNN keys/sec, а вот общий удой по факту (блоков за сутки) будет больше, т.к видео меньше простаивает.

между iter 64 и iter 32 ты на глаз разницы не заметишь. вот между iter 1 и iter 32 - возможно. на монстро-картах, когда iter 1 считается несколько секунд, теряется чуть ли не до 10% надоев.
[RC5] 12.02.09 23:15  
Автор: Sla <Sla> Статус: Member
<"чистая" ссылка>
Кстати, а у GPU клиентов пространсто под рандомы то же самое, что и у CPU? Если да, то скоро рандомные блоки считать будет совсем бесполезно.
[RC5] на монстро-картах (~400М) 10.78 секунд на блок, те ~11 сек. 12.02.09 14:25  
Автор: panam Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Кстати, такая же фигня была в OGR-25, когда массово шли... 12.02.09 14:14  
Автор: Ritual Статус: Незарегистрированный пользователь
<"чистая" ссылка>

>блокисчитаются с одинаковой скоростью. уменьшается
> время, теряемое на их перезагрузку в кранчерах. т.е. ядро
> по-прежнему сообщит те же самые NNN keys/sec, а вот общий
> удой по факту (блоков за сутки) будет больше, т.к видео
> меньше простаивает.

Кстати, такая же фигня была в OGR-25, когда массово шли крохотные блоки. Время, затрачиваемое на изменение файла входного буфера - расшифровку блока - зашифровку результата - изменение файла выходного буфера было сравнимо со временем собственно обсчета блока. Это было в логах видно (скорость расчета крохотных блоков меньше процентов на 10 была).
1






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


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