Chief Delphi
Page 3 of 3 < 12 3
Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   [FRC BLOG] The Great Registration System Crash of 2016 (http://www.chiefdelphi.com/forums/showthread.php?t=151471)

Foster 26-09-2016 10:00
Re: [FRC BLOG] The Great Registration System Crash of 2016
 
Quote:
Originally Posted by Chris is me (Post 1608978)

FIRST should be able to handle a few thousand page requests at once. If they can't, any number of outside firms I'm sure would love to have a contract to do this. This isn't an insurmountable challenge.
Fake News Item: Today FIRST announced that it had outsourced it's entire application suite to a major cloud vendor to improve a computer issue that happens one day per year. In related news, FIRST raised the cost of the initial registration and event by $1800. (*)

I'm not sure why a FIRST Choice like thing wouldn't work. You put your choices in by order you want them. Random selection of team. Is regional / district event available? Yes then book. No then look at second request. Is it booked, Yes then book, No then look at third request, and so on.

Since they hold slots back for rookies, they could easily do this years rookies first (in a random pick) and then the rest of the pool.

That would be far easier to manage and a better use of mentor time than hovering over keyboards trying to snipe a regional like you do a classic Beanie Baby on E-Bay.

Edited to add: The idea by nuclearnerd is also pretty good. It appears we were typing at the same time.

(*) Outsourcing / cloud services are not the inexpensive panacea that many people think. Yea, Yea "well I can spin up an Amazon instance in just a few seconds" sounds easy as heck in a robotics forum, not so easy to do in the real world, especially if you need to manage 1000 transactions per second for any time period.

Those of you that are ready to pound on your keyboards to refute me, don't bother. American has a ton of flights into Manchester, book one and go help them out.

Chris is me 26-09-2016 10:00
Re: [FRC BLOG] The Great Registration System Crash of 2016
 
Quote:
Originally Posted by nuclearnerd (Post 1608984)
This is the easiest thing in the world to automate:
1) Each team submits priority list for their first event.
2) first event slots are raffled off. Some teams receive their second pick instead of their first
3) In the time between the first event and second event raffles, teams can adjust their priority list for the second event. We give the option to choose to be on a "waiting list" for a filled event.
4) Rinse and repeat

This would be a much more equitable system than "may the fastest clicker win" (or perhaps, may the fastest-coded-registration-bot win).
Okay, how does a team get to decide if they are put on the waitlist for the first event, or open registration for the 2nd? What if they only want to be on a waitlist that is X teams long or smaller? Where does a team go if they only have one viable event and it fills?

The current system isn't very "fair", but being able to make these decisions in real time has some benefit that we at least have to think about.

bkahl 26-09-2016 10:09
Re: [FRC BLOG] The Great Registration System Crash of 2016
 
Quote:
Originally Posted by Foster (Post 1608986)
In related news, FIRST raised the cost of the initial registration and event by $1800. (*)

(*) Outsourcing / cloud services are not the inexpensive panacea that many people think. Yea, Yea "well I can spin up an Amazon instance in just a few seconds" sounds easy as heck in a robotics forum, not so easy to do in the real world, especially if you need to manage 1000 transactions per second for any time period.
.
Not too much experience here but that's why I am asking.

Would an upgrade to the website for the registration period really cost $5,400,000+ ($1,800*3000+)? It wouldn't even have to be on the upgraded servers for the entire year. This number seems exuberantly high.

Foster 26-09-2016 10:13
Re: [FRC BLOG] The Great Registration System Crash of 2016
 
Quote:
Originally Posted by Chris is me (Post 1608987)
Okay, how does a team get to decide if they are put on the waitlist for the first event, or open registration for the 2nd? What if they only want to be on a waitlist that is X teams long or smaller? Where does a team go if they only have one viable event and it fills?

The current system isn't very "fair", but being able to make these decisions in real time has some benefit that we at least have to think about.
How complicated do you want it to be? (I didn't know that the current system will tell you how deep in the waitlist you are).

So your choice list would look like this:

If event1 available book_it
If event1 (waitlist < 10) book_it
If event2 (available) book_it
if event1 (waitlist < 25) book_it
if event2 (waitlist < 10) book_it
if event3 (available) book_it

It just goes down the list until something works and then you are done.

Write some specs up, there are about 3000 coders lurking here that would love to write a sample program on how it could work.

Chris is me 26-09-2016 10:25
Re: [FRC BLOG] The Great Registration System Crash of 2016
 
Quote:
Originally Posted by Foster (Post 1608989)
How complicated do you want it to be? (I didn't know that the current system will tell you how deep in the waitlist you are).

So your choice list would look like this:

If event1 available book_it
If event1 (waitlist < 10) book_it
If event2 (available) book_it
if event1 (waitlist < 25) book_it
if event2 (waitlist < 10) book_it
if event3 (available) book_it

It just goes down the list until something works and then you are done.

Write some specs up, there are about 3000 coders lurking here that would love to write a sample program on how it could work.
The current system tells you a green, yellow, red indication of roughly how long the waitlist is, but not an exact number. So I guess it only needs to be that specific. I guess it wouldn't be that hard to code something like this, but I'm hesitant to rely on even more custom software and logic for this sort of thing, considering the track record from FIRST recently of their web interfaces and whatnot.

Foster 26-09-2016 10:28
Re: [FRC BLOG] The Great Registration System Crash of 2016
 
Quote:
Originally Posted by bkahl (Post 1608988)
Not too much experience here but that's why I am asking.

Would an upgrade to the website for the registration period really cost $5,400,000+ ($1,800*3000+)? It wouldn't even have to be on the upgraded servers for the entire year. This number seems exuberantly high.
It was a high guess based on needing to do a total rewrite of the existing functionality and databases by one of the big 6 IT consulting firms. From what I remember there are about 30 screens of stuff on the website for TIMs, award submission and event registration stuff. I guessed at the number of function points (Google Function Point Analysis) required and used $1800 per function point (from the last project I worked on that had that kind of transaction rates (mutual fund user facing transaction system that had to do 500 TPS) and got to just under $3.5 million. Add 50% overrun, etc and there you go.

It's an estimate, could it be done for less, sure. Point was it's going to cost money and FIRST teams are not happy what they pay now. Even if it was $300 per team (~$1 million) there would be lots of complaining.

There may be better ways to do it than brute force. (A concept that works for computer systems and also works for robots :cool: )

Thanks for the question, hope this helped.

Foster 26-09-2016 10:47
Re: [FRC BLOG] The Great Registration System Crash of 2016
 
Quote:
Originally Posted by Chris is me (Post 1608990)
The current system tells you a green, yellow, red indication of roughly how long the waitlist is, but not an exact number. So I guess it only needs to be that specific. I guess it wouldn't be that hard to code something like this, but I'm hesitant to rely on even more custom software and logic for this sort of thing, considering the track record from FIRST recently of their web interfaces and whatnot.
The nice thing is that it can be a standalone system.

Let me blue sky this for a second.

Lets use a simple scripting language like Lua. Lets assume that all the events have a 4 letter code. Users would create a Lua script and submit via text box.

Code:
If EVNA.available then EVNA.register;  -- first choice
If EVNA.green then EVEA.register; -- short wait list, that works
If ABCD.available then ABCD.register; -- lets see about event #2
if EVEA.yellow then EVEA.register; -- didn't get it, check on event 1 list
if ABCD.yellow them ABCD.register; -- rats, how long is the wait for #2
if XYZY.available then XYZY.register; -- sigh, ok what about event 3
-- nothing available that I want, just register on the first event and hope
EVNA.register; -- fingers crossed
Website just does a parse check to see if the code compiles, save to text field in data base.

On registration day, just pull the scripts out one by one and run them. I'd save the "random number" order so that if something bad happened I could re-run the same order again. (or run with a specific seed to the random function)

marshall 26-09-2016 12:04
Re: [FRC BLOG] The Great Registration System Crash of 2016
 
Quote:
Originally Posted by bkahl (Post 1608988)
Not too much experience here but that's why I am asking.

Would an upgrade to the website for the registration period really cost $5,400,000+ ($1,800*3000+)? It wouldn't even have to be on the upgraded servers for the entire year. This number seems exuberantly high.

frcguy 27-09-2016 11:55
Re: [FRC BLOG] The Great Registration System Crash of 2016
 
Quote:
Originally Posted by Gary Dillard (Post 1608674)
Look for metal shavings in a pwm port; that's caused us to crash plenty of times.
At Chezy Champs, the field supervisor found a bumper pin in a team's MXP port. I wonder why they were having issues...


All times are GMT -5. The time now is 14:38.
Page 3 of 3 < 12 3
Show 100 post(s) from this thread on one page

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi