Sieve:- Pick A Range

[Joe O]

In the attached graph, factors found for the combined sieving effort are color coded as follows:
PSP
SB

The lighter colors in these graphs are the most recent results.

As you can see, the leading edge has reached 17000T (17.0P).

[mazadillon]

Originally Posted by Joe O

the leading edge has reached 7000T (7.0P).

the leading edge has reached 17000T (17.0P)

Quite a significant jump!

[Joe O]

In the attached graph, factors found for the combined sieving effort are color coded as follows:
PSP
SB

The lighter colors in these graphs are the most recent results.

As you can see, the leading edge has reached 21800T (21.8P).

[Joe O]

In the attached graph, factors found for the combined sieving effort are color coded as follows:
PSP
SB
SB for January 2009

The lighter colors in these graphs are the most recent results.

As you can see, the leading edge has reached 25100T (25.1P).

[Joe O]

In the attached graph, factors found for the combined sieving effort are color coded as follows:
PSP
SB
SB for February 2009

The lighter colors in these graphs are the most recent results.

As you can see, the leading edge has reached 29390T (29.4P).

[Joe O]

In the attached graph, factors found for the combined sieving effort are color coded as follows:
PSP
SB
SB for March 2009

The lighter colors in these graphs are the most recent results.

As you can see, the leading edge has reached 33900T (33.9P).

[mazadillon]

Can you make sure that people know to submit their SoB factors as well please? It isn't immediatley clear in the first post of this thread. The submit page on the reservation site can automatically submit to both projects.

[opyrt]

Also, it seems that sieveimport.php will report "Input contained 0 lines with already known factor." even if the factor is known.

Usually, it's no big deal, but it is a bit annoying when doing clean-up on a range that someone reserved and never finished. In these cases, it is nice to know how many of the factors are new.

So if you have the spare time, could you look into this? :)

[ltd]

Do you have an example where it happened?

Edit:

The only reason I could think of that it happens is when you resieve a very old range where the factors are already removed from the transfer table for performance reasons.

The factor check does not run against the main database as this would be to slow. There is only a check against all factors in the transfer table. Later on when it comes to the real statistics the data from the transfer table is used to check if there is a factor in the main databse and only give points if there is none.

[opyrt]

Well, that explains it then. :-)

Do you think it's still a performance issue running check againt the main database? I know SoB checks against the live database somehow. And number of factors submitted now are much lower than they used to be.

[ltd]

Sorry for the delay.
Here my answer to your question. In principle it would be possible to have the direct access but there are two problems.

1. I have split the data into different databases so that the web interface SQL user has only very restricted access to some tables in special he has no access to the main DB at all. So even if the web account is hacked there should be no way to damage the main DB. (As long as there are no other security holes. But most of it could also be done using the main database and special access rights.

2. The performance problem itself has two reasons.
There is the number of entries in the main DB that slows things down but I think with the hardware the server is running on this would be OK
But there is also a design error in the main table that makes each row bigger then it should and this is the main reason for the slowdown when acccessing the table for lookup reasons.

I know how the structure should really look like but changing the structure would mean that I have to change all the scripts and test all these changes which means a lot of work and there are several things with much higher priority for which I do not find enough time.