"Random"

[carefactornil]

So we know that anyone clicking the link for the sale between 11:45 and 12:05 will be put in a "waiting room" and then dealt with first (before the "after 12:05"-ers), in an order that is "random".

Except "random" doesn't exist apart from as a concept. Speaking as an ex-coder, you can't program random. You can make something VERY difficult to guess the outcome but true random doesn't exist. Where we think it does (the roll of a dice, say), it's just that we don't have the technology to reliably predict the outcome yet.

What they may have done, to try and simulate "random", is to take the 5th & 10th decimal place (after the seconds value) of the time you entered the room. i.e. if you entered at 11:45:01:1234567890 then this would give a "random" number of 50. Someone entering at 11:45:01:1122334455 would be assigned 35. Which would be near impossible enough to "game" to influence your position. But without knowing what their definition of "random" is, we can't say. Hopefully it's something like I just mentioned which is fairer. And I guess you don't want them to expose what their algorithm for random is otherwise, if it's weak, people WILL try and game it.

Just thought I'd throw that out there as Trilo has closed the other thread about waiting room.

In some ways, I do see this concept of waiting room as more fair than a true "first come first served" approach. Unlike what was said in the waiting room thread it IS absolutely possible to put everyone in a line based on the time the receiving processor gets the requests - that's the default behaviour. But that's just about when the RECEIVE of the requests happened and not necessarily reflective of the order in which they were SENT. If 10,000 folks all hit the same button at roughly the same second round the world, then things like wifi speed, LAN connections, ISPs, which country you're in start to make micro-differences and will perhaps bias in favour of those in some parts of the USA as their "distance" to the server is shorter, even if only by milliseconds. At least the waiting room concept eliminates that. So overall, as long as the algorithm for "random" remains secret, I think this is a wise move.

[ygmir]

I thought this was going to be about The Great Book of Amber.......dang it.

[sadie]

Why are they starting the actual sale at 12:05?
All of the information up until last nights email states that the sale starts at 12:00.
So, for everyone that actually reads their emails, we will all click into the waiting room at 11:45 and try to wait patiently for a decent place in the line.
But for everyone that doesn't read the email, they will all click in at 12:00....which will suddenly fill the waiting room up even further and make the "random" placement for everyone more competitive since the waiting period is still 5 more minutes.
This is not a "whine", just an observation, and statement of confusion.

[Ratty]

Sadie, Good point. I think it's because...if your watch was off by 5 seconds you would be out of luck. they changed the rules in the middle of the game, (so to speak). If some poor burner wasn't aware of the waiting room, waited till the computer clock read 12:00 and hit the button he would be behind the winning pack.

[trilobyte]

If the system has been set up so as to be impossible for either participants or the people running the sale to rig or predict a person's place in line, that's effectively random as far as I'm concerned. Sure, you could debate the programming details or the philosophy of the word if you like, have at it. The other thread was closed because the question had been answered conclusively by the ticket team.

Sadie, the purpose of the waiting room and starting the sale a couple minutes later is so that the servers will be better able to handle the incredibly large demand for tickets. As you may know from previous years' ticket on-sales, that exact moment when everybody hits the server at once is absolutely crushing to even the biggest of ticketing providers. Tens of thousands of people all hitting the same location at once has a tendency to overload the system and prevent anyone from getting through. As we've seen in the past with previous ticketing providers, and I still see happen today with some concert and event on-sales, when the servers completely choke up the queues seize up or dump users, leaving those who were there first to have to start the process over and get behind so many others. It was bad enough when only a couple thousand burners were queueing on the first day, now that demand is so much greater than supply that could be the difference between being able to get tickets... and not.

Starting a couple minutes later and putting that initial batch into a waiting room (one that still gets in ahead of those who arrive after the start of the sale) allows them to manage the flow and prevent those kinds of problems.

[jneilvindy]

May the odds be ever in our favor today my burner buddies!

[Ratty]

I'm not gonna say who, but somebody looks ridiculous. This isn't all bad.

[carefactornil]

I dare say we're going to see a lot of chatter on here & social media afterwards about when people got in the waiting room and when/if they got through to the actual sale. Hopefully we'll be seeing as much evidence that folks at 11:45:00 and 12:04:59 got served equally quickly.

[Ratty]

You ever notice on Yelp that the unhappy posters write longer comments than the happy people. And there are more of them. I predict that everyone posting here signed into the waiting room at 11:45 exactly and was froze out.

[trilobyte]

I think that regardless of the outcome, there will be a lot of people posting on social media about their experience and how they got screwed in one way or another. It's unfortunate, but that's a byproduct of scarcity.

Demand for tickets increases pretty much every year. The ticket supply has not increased. In fact, this year's main sale has 10K fewer tickets (allocations in other sales has increased).

[hootley]

I'm guessing there were obviously more people in the waiting room than there were tickets available. I'd love to find out if anyone that clicked in after 12:05 was able to get a ticket, though.

[carefactornil]

Hmm. Well I got zero, despite getting through to the ticket page where it THEN kept saying none available. Not great expectation management!

I know that'll mostly likely change and I'll get them somewhere, but what I heard from many friends out there is that people who got in the waiting room lucked out. Those who joined the sale at 12:06 went straight to the ticket page. If that turns out to be true then that's seriously messed up IT. Stuff worrying about what "random" actually means, that would be very disappointing.

[sandfly]

I understand the point that computer-simulated "random" doesn't produce mathematical randomness. But, I don't understand how that lets someone (e.g. a scalper with lots of resources) improve their chances by gaming the system. Assuming Ticketfly assigns places in the queue based on those remote decimal points at the time of the click, (a) I doubt that even scalpers have the technology to time their clicks to get early queue placement based on those tiny factions of seconds within a 20 minute window, and (b) if Ticketfly keeps their system proprietary (secret), then those super-tech scalpers wouldn't even know which microsecond digits to target.

As word gets out that places within a ~20 minute window all clicks get treated the same, that will abate the server overload problem because we won't get 40,000 (or, whatever) people trying to click at 12:00:00.

I also like that, for most of us, whether we get a ticket (I didn't) in the lottery really just comes down to luck and not because we were out-gamed or out-clicked by somebody else.

But, as with almost all of the universe, there's a nearly infinite amount that I don't know, so if there's some way to game a computer's psuedo-random ticket queue assignment system, I'd be curious to know how that works.

[BBadger]

I do wonder if there was a fuck-up that allowed new arrivals/refreshers got in before those waiting in line. Anecdotally, some friends who got tickets mentioned that they had waited a long time and then only after refreshing the browser manually were able to get in immediately, rather than following the instructions to just wait patiently in the queue.

So I wonder if it was it even a queue, or if it just happened to choose whomever requested the page at that particular moment. In the future, I'd probably just say "fuck it" to those instructions and try and cover both bases by manually refreshing at a more frequent interval. It's not like they state that they'll punish you by moving you further back in line.

[gateway]

I had the same issue along with 8 other friends of mine who went the waiting room route, none of us were able to get tickets.. so not so random. I think what might of happened is the amount of people in the room ticketfly keeps that data of maybe codes cached in but it could of been when the 12:05 triggered none of those where refreshed properly into the que because it seems that from what I'm hearing from some people who just clicked after 12:05 their man ran across the screen and where able to get tickets.

Of course we will never know nor do I think BM will even bring this up since every year people don't get tickets and have to rant a bit.

btw, just fyi.. have a background in backend development so I know how inner workings work and stuff does happen from time to time where the end result is not favorable.

[gateway]

I do wonder if there was a fuck-up that allowed new arrivals/refreshers got in before those waiting in line. Anecdotally, some friends who got tickets mentioned that they had waited a long time and then only after refreshing the browser manually were able to get in immediately, rather than following the instructions to just wait patiently in the queue.

So I wonder if it was it even a queue, or if it just happened to choose whomever requested the page at that particular moment. In the future, I'd probably just say "fuck it" to those instructions and try and cover both bases by manually refreshing at a more frequent interval. It's not like they state that they'll punish you by moving you further back in line.

usually refreshing can open up a new socket to what ever server is healthy at the time. When I mean healthy its how many requests can each sever take before they stop taking them, so in theory refreshing could of taken someone via the load balancer to a new server that had luckily open sockets and room to take requests. Thus pushing them into a line ahead of others.

[tamarakay]

It did seem to help the servers out. That part of it was way less stressful than last year. But the couple times I was booted out last year, when i got back in i was returned to my same place in line.

[Zaxary]

It must be an interesting challenge, at least, for the techy folk at Ticketfly and/or BM who program the sale. Can you imagine the project planning that went into making the past couple of hours happen? Whatever they decided to do to make the sale random or random-esque, they did something big and pretty damn cool.

Anecdotal reports from 'round here... some people were running multiple devices & browsers (something something about separate IP something) that they activated within milliseconds of each other, and their queues were running at wildly different speeds. Some made it, some didn't. Some people were running one device and those people's queues were all moving along at different paces. We had a group chat running and the order of access to tickets seemed to have nothing to do with the order of clicking the sale link / seeing the waiting room page. I have no idea how it's all programmed but it felt pretty random as a consumer.

[BBadger]

usually refreshing can open up a new socket to what ever server is healthy at the time. When I mean healthy its how many requests can each sever take before they stop taking them, so in theory refreshing could of taken someone via the load balancer to a new server that had luckily open sockets and room to take requests. Thus pushing them into a line ahead of others.

Though the unfortunate aspect is that people were expecting the queue to be an actual deterministic queue.

If the system is not going to enforce rules that honor the expectations of the instructions, and only serves to penalize those who do follow the instructions, there's no point people honoring the instructions either. As I mentioned before, in the future, I'll be advising people to simply ignore the false instructions given by Ticketing, and keep refreshing as much as possible.

[gateway]

usually refreshing can open up a new socket to what ever server is healthy at the time. When I mean healthy its how many requests can each sever take before they stop taking them, so in theory refreshing could of taken someone via the load balancer to a new server that had luckily open sockets and room to take requests. Thus pushing them into a line ahead of others.

Though the unfortunate aspect is that people were expecting the queue to be an actual deterministic queue.

If the system is not going to enforce rules that honor the expectations of the instructions, and only serves to penalize those who do follow the instructions, there's no point people honoring the instructions either. As I mentioned before, in the future, I'll be advising people to simply ignore the false instructions given by Ticketing, and keep refreshing as much as possible.

I have a sneaky feeling that something just didn't work right. Users who would refresh or just come in after the 12:05 seemed to have had the most luck.