информационная безопасность без паники и всерьез  подробно о проекте
			Анализ криптографических сетевых...   Модель надежности двухузлового...   Специальные марковские модели надежности...   Очередное исследование 19 миллиардов...   Оптимизация ввода-вывода как инструмент...   Зловреды выбирают Lisp и Delphi
	главная обзор RSN блог библиотека закон бред форум dnet о проекте
	bugtraq.ru / форум / dnet		Имя Пароль

	если вы видите этот текст, отключите в настройках форума использование JavaScript

ФОРУМ
	все доски
	FAQ
	IRC
	новые сообщения
	site updates
	guestbook
	beginners
	sysadmin
	programming
	operating systems
	theory
	web building
	software
	hardware
	networking
	law
	hacking
	gadgets
	job
	dnet
humor
miscellaneous
scrap
регистрация

Легенда:   новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение

• Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
• Новичкам также крайне полезно ознакомиться с данным документом.

Командная прокся 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

Copyright © 2001-2025 Dmitry Leonov

Page build time: 0 s

Design: Vadim Derkach