Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
[RC5] 12.02.09 09:59 Число просмотров: 2508
Автор: stream <Roman Trunov> Статус: Member
|
> не сказал бы что примерно 3гигакея
> сильно грузят 1 проксю на стареньких атлонах мп в
> количестве 2х штук.
Это не для проксей было сделано, а для клиентов. На быстромолотящих видеокартах, где обычный RC5-блок считается всего несколько секунд, становится заметным время чтения/записи блока из буферов - видеокарта простаивает, общая скорость падает. Поэтому сделали блоки большего размера, чтобы можно было пожевать подольше.
А обновляться с началом OGR-27 все равно придется. Т.е максимум через пару недель в любом случае.
|
|
<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 была).
|
|
|
подробно о проекте
Анализ криптографических сетевых...
