Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Конкретно по этой строчке - ничего военного. Если новый... 28.08.13 09:27 Число просмотров: 3510
Автор: stream <Roman Trunov> Статус: Member
|
Конкретно по этой строчке - ничего военного. Если новый ruler был бы найден в combined stub, он передавался обратно мастеру немного не в том формате, и мастер не находил его в списке валидных блоков. Т.к. параллельно пишутся и анализируются еще и текстовые логи, мы бы все равно увидели положительный результат, но с точки зрения мастера проект "подвис" бы с одним блоком, который никак не может обработаться. Вылезло как побочный эффект после исправления другого бага, поэтому и regression.
В багзилле баг 4295 - закрытый.
|
|
<dnet>
|
[OGR] Клиенты версии 520 27.08.13 17:58
Автор: Ritual Статус: Незарегистрированный пользователь
|
Начали появляться клиенты версии 520, у них в CHANGES.TXT есть такая строчка:
fix: all: regression in OGR-NG codebase (#4295)
Кто-нибудь знает, что это? Бугзилла не хочет показывать баг с этим номером :(
|
|
Конкретно по этой строчке - ничего военного. Если новый... 28.08.13 09:27
Автор: stream <Roman Trunov> Статус: Member
|
Конкретно по этой строчке - ничего военного. Если новый ruler был бы найден в combined stub, он передавался обратно мастеру немного не в том формате, и мастер не находил его в списке валидных блоков. Т.к. параллельно пишутся и анализируются еще и текстовые логи, мы бы все равно увидели положительный результат, но с точки зрения мастера проект "подвис" бы с одним блоком, который никак не может обработаться. Вылезло как побочный эффект после исправления другого бага, поэтому и regression.
В багзилле баг 4295 - закрытый.
|
| |
[OGR] Конкретно по этой строчке - ничего военного. Если новый... 28.08.13 18:44
Автор: Ritual Статус: Незарегистрированный пользователь
|
Ясно, спасибо.
Собственно и не верится, что мы в OGR-27 найдем новый рулер, поэтому обновить клиентов можно будет между OGR-27 и OGR-28 (там-то известный рулер не оптимальный почти наверняка).
|
| | |
Обновлять на 520 необязательно, ну разве что если там вдруг... 28.08.13 22:18
Автор: stream <Roman Trunov> Статус: Member
|
Обновлять на 520 необязательно, ну разве что если там вдруг появились более быстрые ядра для твоего процессора. Даже если какой-то стаб вдруг "подвиснет" - мы это все равно заметим, ибо он и будет "выигрышным". Для оптимальной работы проекта достаточно 518 и выше. Если совсем сложно обновлять ферму, можно даже использовать и более старые клиенты, но их результаты должны подтверждаться результатами от 518+, так что часть работы по теории вероятности гарантированно уйдет впустую.
> поэтому обновить клиентов можно будет между OGR-27 и
> OGR-28 (там-то известный рулер не оптимальный почти
> наверняка).
Это да. Для тех, кто не вдавался в детали - рулер OGR-28 есть рулер от OGR-27 с приписанным к нему в хвост одним дополнительным числом. Чего ранее никогда не встречалось. Либо это действительно такая уникальная комбинация, либо один из рулеров неоптимален.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
