Some data has been corrected today:
tpt k=24 - is 0 tuples corrected
tpt k=22 - is 12 tuples corrected
tpt k=20 - is 123 tuples corrected
tpt k=18 - is 2604 tuples corrected
tpt k=16 - is 47799 tuples corrected
tpt total = 50538 tuples corrected

The cause of the errors was in the assimilator.
This has now been resolved.

Data analysis work will continue.

---

Some tasks counted by crunchers went into an error state.
However, no credits were assigned for these tasks.

Moreover, it is absolutely certain that these tasks were calculated normally.
And the answer from them is present in the database.

For all such tasks, statistics were recalculated and credits were assigned.
The following text has been added to the captions for such tasks:

Validation rechecked, correct credit, calculated, fixed and assigned. v.1.0

(Example: https://boinc.termit.me/adsl/result.php?resultid=2688050)

"Batch" - "Count err":
103 - 1
111 - 19
113 - 6
115 - 99
117 - 14
119 - 211
121 - 42
123 - 18
125 - 161
129 - 114
131 - 54
133 - 16

The cause of these errors was resolved last week.

---

The cause of these errors was resolved last week.

What was the reason for these errors?
I assume that this is related to the operation of the validator.

Have all the causes of incorrect results (tuples) been eliminated?

There was an error in the assimilator source code published by Tomas.
Because of this error, some of the correct “ofs” results calculated and sent by crunchers showed incorrect start values in the database and, accordingly, on the website too.
There were about 50,000 of them.

There errors in the data database that arose due to hardware errors in the crunchers.
There are not many of them - about 2-3 thousand
(The total number of responses from crunchers is more than 15,000,000).

Such problems will be identified, disqualified, and published for re-counting.
Work on this continues...

It is important to understand that iron errors in crunchers are impossible to predict.
They can only be found after a response has been received.

---

It is important to understand that iron errors in crunchers are impossible to predict.
They can only be found after a response has been received.

Are such errors eliminated by introducing quorum=2?

Yes.
Quorum 2 eliminates this problem.

---

If I remember correctly, you said that the BOINC project TBEG had a quorum=2.
Petukhov discovered many errors in this project specifically in the results (tuples).
Where did they come from?

Please give an example of a WU that was incorrectly calculated due to a hardware error.

Question
If some cruncher gave one wrong solution due to a hardware error, does this mean that this particular cruncher's computer is counting all WUs incorrectly?

Link (Petukhov)
https://dxdy.ru/post1613400.html#p1613400

Example BAD data:

Read data from file 'wu_431428_803879_spt_101_5499119934525935453_1_366_output.dat' :
ident:5499119934525935453
start:5499119934525935453
chkpt:5499121884525935473
last:5499121884525936859
step (last-start):1950000001406
step (chkpt-start):1950000000020
nprime: 2338848025
status: 1
status2: 2
sieve_init_cs: 208
twin_gap_d: 886
twin_gap_6d: 400
data:
tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773905876457 k=16 kind=0 (spt) deriv=0 ofs=2 24 18 46 24 18 30 32
tuple find: 5499120970980195589 k=16 kind=0 (spt) deriv=0 ofs=10 20 4 18 12 48 2 34
tuple find: 5499121126535252239 k=13 kind=0 (spt) deriv=0 ofs=24 6 60 42 18 12
tuple find: 5499121316841673511 k=16 kind=0 (spt) deriv=0 ofs=2 24 24 28 24 56 4 14
tuple find: 5499121483035391399 k=16 kind=0 (spt) deriv=0 ofs=40 8 22 12 8 22 48 32
tuple find: 5499121558853990699 k=16 kind=0 (spt) deriv=0 ofs=14 16 2 42 6 10 54 86
tuple find: 5499121733722103317 k=16 kind=0 (spt) deriv=0 ofs=42 10 44 34 2 58 42 2
tuple find: 5499121775895727829 k=16 kind=0 (spt) deriv=0 ofs=12 56 46 116 10 8 34 8
tuple find: 5499121234826549117 k=10 kind=1 (stpt) deriv=0 ofs=2 10 2 58 2
tuple find: 5499121440577613711 k=10 kind=1 (stpt) deriv=0 ofs=2 34 2 40 2
tuple find: 5499121475147240399 k=10 kind=1 (stpt) deriv=0 ofs=2 16 2 10 2
tuple find: 5499121591027137257 k=10 kind=1 (stpt) deriv=0 ofs=2 28 2 28 2
tuple find: 5499121666242136481 k=10 kind=1 (stpt) deriv=0 ofs=2 4 2 40 2
tuple find: 5499121680143694047 k=10 kind=1 (stpt) deriv=0 ofs=2 28 2 10 2
tuple find: 5499121740427855217 k=10 kind=1 (stpt) deriv=0 ofs=2 10 2 28 2
tuple find: 5499121817057916077 k=10 kind=1 (stpt) deriv=0 ofs=2 28 2 28 2
end data.
primes.empty() = 0
count: 18
Done.

All binary data fields is correct.
Do not have destroyed nothing.

But correct data (for these task) is:

Read data from file 'output_101_5499119934525935453-manual.dat' :
ident:5499119934525935453
start:5499119934525935453
chkpt:5499121884525935473
last:5499121884525936859
step (last-start):1950000001406
step (chkpt-start):1950000000020
nprime: 2240302156
status: 1
status2: 2
sieve_init_ms: 4080 (4 sec)
twin_gap_d: 886
twin_gap_6d: 400
data:
tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773581271527 k=16 kind=0 (spt) deriv=0 ofs=22 18 30 12 50 18 52 8
tuple find: 5499121289947186217 k=16 kind=0 (spt) deriv=0 ofs=44 6 16 44 24 6 16 8
tuple find: 5499121372440344689 k=16 kind=0 (spt) deriv=0 ofs=34 18 2 54 46 104 6 94
tuple find: 5499120954814009877 k=14 kind=2 (tpt) deriv=0 ofs=70 58 10 76 118 40
tuple find: 5499121634173665539 k=10 kind=1 (stpt) deriv=0 ofs=2 16 2 10 2
end data.
primes.empty() = 0
count: 7
Done.

We see:
tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773905876457 k=16 kind=0 (spt) deriv=0 ofs=2 24 18 46 24 18 30 32
...
...
and
tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773581271527 k=16 kind=0 (spt) deriv=0 ofs=22 18 30 12 50 18 52 8
...
...
After line 2 the data is incorrect.
The number of entries in the list is also different.

---

Example BAD data:

Что такое "плохие данные"?

1. Был задан вопрос

If I remember correctly, you said that the BOINC project TBEG had a quorum=2.
Petukhov discovered many errors in this project specifically in the results (tuples).
Where did they come from?

Ответа на этот вопрос не вижу.

2. Была просьба

Please give an example of a WU that was incorrectly calculated due to a hardware error.

Я просила привести ОДИН пример конкретного задания (WU), которое пришло от кранчера неправильно посчитанным из-за аппаратного сбоя.

Такой пример я тоже не вижу.
В вашем сообщении МНОГО примеров. но я не понимаю, какого типа в них ошибки.
Повторяю просьбу.
Мне надо увидеть неправильное решение, которое поступило в БД от кранчера, имеющего "плохой" компьютер, который неправильно считает и выдаёт неверные решения (кортежи).
У вас есть такой конкретный пример?
WU у вас как задаётся?
Ну то задание, которое получает кранчер).
Вот мне надо видеть этот WU, и увидеть, какие результаты пришли для этого WU от кранчнра, который имеет на своём компьютере аппаратные сбои.
Моя просьба вам понятна?

3. Был задан вопрос

Question
If some cruncher gave one wrong solution due to a hardware error, does this mean that this particular cruncher's computer is counting all WUs incorrectly?

Ответ на этот вопрос тоже не вижу.

Вот, например, у вас (это то, что можно как-то воспринять)

"We see:
tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773905876457 k=16 kind=0 (spt) deriv=0 ofs=2 24 18 46 24 18 30 32"
Последнее решение (выделенное красным) неверное?
Я правильно понимаю.

Это решение появилось именно из-за аппаратного сбоя?
Или это другого типа ошибка?

The number of entries in the list is also different.

Я не знаю, что такое "количество записей в списке".

Это число начинает неправильную 16-ку?
5499120773905876457
Пожалуйста, покажите её полностью, то есть с паттерном, чтобы я могла проверить этот кортеж.
Пусть он неправильный.

1. Если этот неправильный кортеж появился из-за аппаратного сбоя у кранчера, вы можете определить причину этого сбоя?

2. Вы можете сказать, какой кортеж вместо этого неправильного должен быть записан в БД?
Ведь чтобы исправить эту ошибку, вам необходимо знать верный результат.
Разве не так?
Или в тех данных, которые приходят от кранчера, вы можете увидеть правильное решение?
Тогда вы должна понимать, что же и на каком этапе нарушается.

Пожалуйста, отвечайте по-русски.
Слишком много вопросов!
Вряд ли мы и по-русски разберёмся.
Прошу отвечать на все мои вопросы по порядку и подробно.

Если же вы считаете это "опять бла-бла-бла", продолжайте гнать брак.

Ведь аппаратные сбои у кранчеров никто не отменил, как я понимаю.
И эти компьютеры продолжают посылать в БД неправильные решения.

Вот вам конкретный пример.

Первая ошибка, указанная Петуховым (ссылка выше)

SPT18

1077860824462209253: 0 46 58 60 76 90 118 120 130 186 196 198 226 240 256 258 270 316

Этот кортеж я могу проверить программой Белышева.

1) Начала считать с 1077860820000000000
Найдена 16-ка

1077861133286808397: 0 30 42 46 66 90 142 172 174 204 256 280 300 304 316 346

2) Начала считать с 1077860800000000000 (ещё раньше)
Найдена та же 16-ка

1077861133286808397: 0 30 42 46 66 90 142 172 174 204 256 280 300 304 316 346

Яано неверное решение.
Никакой 18-ки и близко нет ( в окрестностях указанного начального элемента кортежа).
Может быть, начальный элемент 18-ки сильно дальше указанного начального элемента?
Или наоборот сильно раньше?
Но как узнать, где же конкретно?.

Из-за чего возникла эта ошибка?
Это аппаратный сбой?
Или это что-то другое?
Вы знаете, какой правильный кортеж должен быть вместо этого неправильного?
То есть как исправить эту ошибку?

А теперь про кворум=2.
Вы писали мне в письме (если я не путаю), что в проекте TBEG кворум=2 действовал.

Тогда объясните мне, пожалуйста, как в БД появился кортеж, который я показала выше?
Это неверное решение!
Как оно могло пройти через защиту кворумом?

И наконец.
Сейчас вы написали, что кворум=2 решит проблему ошибок, возникающих из-за аппаратного сбоя.

Yes.
Quorum 2 eliminates this problem.

Что помешало вам за несколько месяцев ввести уже этот кварум=2?
Я же вам теперь не мешаю.

Вот, например, у вас (это то, что можно как-то воспринять)

"We see:
tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773905876457 k=16 kind=0 (spt) deriv=0 ofs=2 24 18 46 24 18 30 32"
Последнее решение (выделенное красным) неверное?

Да.
Но уточню, что оно и все последующие за ним

Я правильно понимаю.

Правильно.

Это решение появилось именно из-за аппаратного сбоя?

Предполагаю, что да.

Или это другого типа ошибка?

Не похоже.

The number of entries in the list is also different.

Я не знаю, что такое "количество записей в списке".

Там список строк начинающихся со слов "tuple find:"
Плюс счетчик всех этих строк "count:"

Это число начинает неправильную 16-ку?
5499120773905876457

Это вообще не понятное число, в том смысле, что неизвестно откуда оно появилось. Его там быть не должно.

Пожалуйста, покажите её полностью, то есть с паттерном, чтобы я могла проверить этот кортеж.

Это и показано в моем посте.
Смотрите внимательно k=16 или я не правильно Вас понял.

Пусть он неправильный.

1. Если этот неправильный кортеж появился из-за аппаратного сбоя у кранчера, вы можете определить причину этого сбоя?

Боюсь, что нет.
Вариантов, причин происходящего, было рассмотрено большое количество.
Но достоверного ответа - нет ни одного.
Ошибка у кранчеров возникает на разных компьютерах, разных пользователей, разном железе.
Но очень не часто.

Закономерностей не обнаружено.
Всего 0.02% из более 15 миллионов ответов.

У меня был алгоритм как найти плохие ответы.
Но сейчас он утерян.
(Ноутбук сломался еще в январе).
Когда находил список "проблемных" решений, оставалось его только пересчитать локально.
Чтобы перепроверить, что это действительно не правильные данные от кранчера.

2. Вы можете сказать, какой кортеж вместо этого неправильного должен быть записан в БД?

Правильный я Вам сразу привел, чтобы видно было и можно было сравнить. Т.е. "что получено" от кранчера и "как должно быть". Пересмотрите снова.

Ведь чтобы исправить эту ошибку, вам необходимо знать верный результат.
Разве не так?

Только пересчитывать. (Локально или через кранчеров - это уже частности.)

Пожалуйста, отвечайте по-русски.
Слишком много вопросов!

Именно! Но Вам-же это не интересно было? Тема была поднята в моем письме от 12-го августа.

Вряд ли мы и по-русски разберёмся.
Прошу отвечать на все мои вопросы по порядку и подробно.

Только когда есть время.

Если же вы считаете это "опять бла-бла-бла", продолжайте гнать брак.

Это не от меня зависит.

Ведь аппаратные сбои у кранчеров никто не отменил, как я понимаю.
И эти компьютеры продолжают посылать в БД неправильные решения.

Да.
Мной неоднократно писалось, что есть более важные задачи.
И это одна из них.

И также я писал, что работа продолжается.
Есть разные соображения, что с этим делать.
Но они пока не оформлены в коде.

---

Это не от меня зависит.

А от кого это зависит?

Вы говорите, что кворум=2 спасёт от ошибок, возникающих из-за аппаратного сбоя.
Так введите кворум=2!
Что вам мешает?
И от кого это зависит?
Вы один управляете проектом.
Так управляйте!
Чтобы проект давал только правильные результаты.
А неправильные, если они всё-таки появляются, чтобы немедленно исправлялись.

Надо выявить все причины возникновения ошибок.
Работа всех вспомогательных модулей (валидатор, ассимилятор).
Работа клиентской программы.
И так далее.

Сама рабочая программа Белышева не даёт никаких ошибок!

Пересмотрите снова.

Что я должна пересмотреть???
Вы писали

"We see:
tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773905876457 k=16 kind=0 (spt) deriv=0 ofs=2 24 18 46 24 18 30 32"

Я спросила

Последнее решение (выделенное красным) неверное?

Вы ответили "Да".

Я прошу вас показать верное решение в понятном мне формате с паттерном и с начальным элементом кортежа (ваш формат я не понимаю).
Это трудно показать?
Или "нет времени"?

А ещё прошу рассказать, как вы нашли правильное решение взамен показанного неправильного.

Вот это правильный результат (выделенный зелёным)?

tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773581271527 k=16 kind=0 (spt) deriv=0 ofs=22 18 30 12 50 18 52 8

Повторяю вопрос: как вы нашли правильное решение?

Вот стандартная запись кортежа

5499120773581271527: [0, 22, 40, 70, 82, 132, 150, 202, 210, 262, 280, 330, 342, 372, 390, 412]

Эту запись я и просила вас привести.

Итак, каким же чудесным образом вы угадали правильное решение???
Вы пересчитывали всё WU?

А что во всём WU?
Какой интервал кранчер получает в одном WU?

Только когда есть время.

Задолбали своим временем.
Толку от вас не будет никакого.
Как проект гнал брак, так и будет гнать.

Мне, конечно, делать совершенно нечего, вот и пришла с вами "поболтать" - от нечего делать.
Думала, что вы немножко по-другому будете разговаривать.
Но горбатого могила исправит.

Пересмотрите снова.

Что я должна пересмотреть???

https://boinc.termit.me/adsl/forum_thread.php?id=67&postid=696#696

Вы писали

"We see:
tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773905876457 k=16 kind=0 (spt) deriv=0 ofs=2 24 18 46 24 18 30 32"

Я спросила

Последнее решение (выделенное красным) неверное?

Вы ответили "Да".

Я прошу вас показать верное решение в понятном мне формате с паттерном и с начальным элементом кортежа (ваш формат я не понимаю).
Это трудно показать?

Я показываю в формате как хранится и извлекается сервером.
Чтобы исключить не верность пересчета в банальном.
Мне так проще.
Неужели это не понятно?

Или "нет времени"?

А ещё прошу рассказать, как вы нашли правильное решение взамен показанного неправильного.

Как писал выше - только пересчетом. Т.е. такое задание было пересчитано программой spt которая есть у каждого кранчера.
И таки - да.
Это занимает два часа времени.
На том компьютере где это у меня считалось.

Вот это правильный результат (выделенный зелёным)?

tuple find: 5499120046153320487 k=16 kind=0 (spt) deriv=0 ofs=54 30 10 2 34 20 22 2
tuple find: 5499120251551369451 k=16 kind=0 (spt) deriv=0 ofs=30 20 76 36 20 10 50 4
tuple find: 5499120773581271527 k=16 kind=0 (spt) deriv=0 ofs=22 18 30 12 50 18 52 8

Да

Повторяю вопрос: как вы нашли правильное решение?

Пересчитал.

Вот стандартная запись кортежа

5499120773581271527: [0, 22, 40, 70, 82, 132, 150, 202, 210, 262, 280, 330, 342, 372, 390, 412]

Эту запись я и просила вас привести.

Пожалуйста:
5499120046153320487: [0, 54, 84, 94, 96, 130, 150, 172, 174, 196, 216, 250, 252, 262, 292, 346]
5499120251551369451: [0, 30, 50, 126, 162, 182, 192, 242, 246, 296, 306, 326, 362, 438, 458, 488]
5499120773581271527: [0, 22, 40, 70, 82, 132, 150, 202, 210, 262, 280, 330, 342, 372, 390, 412]
5499121289947186217: [0, 44, 50, 66, 110, 134, 140, 156, 164, 180, 186, 210, 254, 270, 276, 320]
5499121372440344689: [0, 34, 52, 54, 108, 154, 258, 264, 358, 364, 468, 514, 568, 570, 588, 622]
5499120954814009877: [0, 2, 72, 74, 132, 134, 144, 146, 222, 224, 342, 344, 384, 386]
5499121634173665539: [0, 2, 18, 20, 30, 32, 42, 44, 60, 62]
Но перепроверяйте сами, т.к. делал вручную.

Итак, каким же чудесным образом вы угадали правильное решение???
Вы пересчитывали всё WU?

Да.

А что во всём WU?

Показал выше.

Какой интервал кранчер получает в одном WU?

5499119934525935453..5499121884525935453 (step:1950000000000)

---

И наконец.
Сейчас вы написали, что кворум=2 решит проблему ошибок, возникающих из-за аппаратного сбоя.

Yes.
Quorum 2 eliminates this problem.

Что помешало вам за несколько месяцев ввести уже этот кварум=2?

Здравый смысл...

---

There errors in the data database that arose due to hardware errors in the crunchers.
There are not many of them - about 2-3 thousand
(The total number of responses from crunchers is more than 15,000,000).

As of now we have
888 incorrect answers from crunchers.
All of these incorrect answers come from 162 workunits.

Total number of workunits issued: 2 691 776
Total number of values received: 16 867 165

2691776 = 100%
162 = X
x=0,0060183313916165386718657124515561%

16867165 = 100%
888 = X
x=0,0052646665874199961878596669920523%

These are just current error statistics.

---