End of Auction Issues

December 9, 2001

This is a follow up to an off and on issue with Ebay servers being out of synch with Atomic time.

I received a report today and a Snipe log that clearly shows the issue remains.

Log (snipped to show the issue clearly)

Clock needs synch... Time Server: 129.7.1.66 
Clock synched to Atomic time... 12/8/2001 4:28:37 PM

Checking Official Ebay Time...

Ebay time: Saturday Dec 08 2001 16:28:37 PST
Method 2 Official Time equal to Atomic time

Confirmation Server Time is equal to Atomic time
Trans time is <= selected safety margin (SM: 10) (TT: 0) (SD: 1)
Snipe Time: 12/8/2001 4:33:25 PM

Item Page Server Time is equal to Atomic time

Bid Server Time is equal to Atomic time

Pre Snipe Data Check...

Checking Bidding Server Time
Pre Snipe Data Check complete

Bid Server time is equal to Atomic time

Sniping Now! 12/8/2001 4:33:26 PM

Attempting to connect to Ebay
MARK 12/8/2001 4:33:26 PM
Connected to Ebay
MARK 12/8/2001 4:33:26 PM

{Bid is submitted}

Good-Bye Ebay
MARK 12/8/2001 4:33:26 PM
Disconnected from Ebay
MARK 12/8/2001 4:33:26 PM
Bid Server time is 10 second ahead of Atomic time
We have a big problem!... NO SNIPE!!
Per Ebay: Cannot Proceed...

BIDDING HAS ENDED!

Sniper is connected via Broad Band and the log showed 100% consistent 0 and 1 second transmission times. CJ tracked and adjusted for a 1 second synch difference throughout the count down. The amount of time from Snipe Submission to disconnection from Ebay encompassed 1 second (:26)

Sniper's safety margin was 10 seconds with a 1 second synch difference adjustment. Per the log this Snipe was going to hit the target safety margin +-1 second. The auction ended according to Ebay at:

Dec-08-01 16:33:35 PST (4:33:35 PM)

Of course it is not known if the Sniper would have won this auction but what is known, per the Snipe log, the seller lost $48.29 plus the next minimum increment if this Sniper's bid was not enough to take over the auction. The final price realized for this auction was over $200.

Ebay has officially denied the problem exists however Cricket Jr has for over two years documented the problem exists and continues to exist. What is most interesting about the issue that I have personally witnessed when testing the program is that for the last SEVERAL months when the program records server times, in almost all cases when the server SUDDENLY goes out of synch with Atomic time, the number is between 10 and 12 seconds CONSISTENTLY. Within a minute or two, the server is suddenly back in synch. While testing I have witnessed this [anomaly?] occur more then once in a 10 minute period of time. I get the strong feeling sometimes that there is somebody flipping a little switch to thwart Snipers.

Something to think about...

Rarely do I see the synch difference be more then 10-12 seconds. I often see it be a couple of seconds. Every once in a while 15-17 seconds.

10-12 seconds is a well known number of seconds for a Sniper to use as the time to send in their Snipe bid.

I find it strange that when the issue pops up that Ebay is always ahead of Atomic time, never behind. This seems strange because clocks drift away from Atomic time, not advance.

When I see the time difference be only a couple of seconds, often the difference is what you would expect... the time difference is behind Atomic Time.

Can it be a problem with the Time Server? I don't think so. Cricket 4x Deluxe in Beta now, has approximately 30 Time Servers to choose from. I have changed time servers midstream and synched again. 

We know that Ebay staff on every occasion when dealing with Snipe issue puts a form statement into their email that is anti sniping. We know that on their site they are also negative to Sniping. We know that Ebay has taken measures in the past to stop Snipe programs. In this case however, this time issue thwarts all Snipers, not just ones that use Snipe programs.

Did you notice red bolded (TT:0) above? That represents a 0 transmission delay time. Read Ebay staff member logic behind the error over a year ago and what I said then. The Sniper above has a 5 minute count down period. CJ performed 5 transmission delay tests during the count down. Two resulted in 0 delay and Three resulted in a 1 second delay.

What does a 0 delay really represent? It means that when the program submitted the transmission delay test, it began when a second in time for example :01 was in progress. The result came back before the :01 second expired.

There are a 1000 milliseconds in 1 second. 

The 1 second delay could represent really also nearly a 0 because if the start time occurs for example 50 milliseconds prior to a second in time expiring, it can complete 300 milliseconds after the new second begins. Your computer can I believe accurately measure time easily to the millisecond. With a high resolution timer I don't think it would be much of a problem to get your computer to burp once every 10-20 ms.

In the example above, although it only took 350 milliseconds to make the trip, CJ could report it took 1 second.

If it takes 999ms to make the trip to Ebay and back, 0 delay will be result if those 999ms occurred in the same second in time. This is the +- 1 second margin of error I mention in the CJ Help file.

Here is the full log write disclosing the amount of time it took to make the snipe.

Sniping Now! 12/8/2001 4:33:26 PM

Attempting to connect to Ebay
MARK 12/8/2001 4:33:26 PM

Connected to Ebay
MARK 12/8/2001 4:33:26 PM

Sending in Snipe
MARK 12/8/2001 4:33:26 PM

Snipe Sent
MARK 12/8/2001 4:33:26 PM

Waiting for Ebay to respond
MARK 12/8/2001 4:33:26 PM

Response received
MARK 12/8/2001 4:33:26 PM

Response Completed..., Processing Snipe... (Ebay has bid in hand?)
MARK 12/8/200