[arrl-odv:31433] LOTW Delays After CQWW CW
Asked a number of my contesting friends about the LOTW delays after CQWW CW. None of them are upset about it. The delay is not unexpected. One comment was that it isn't unusual for there to be longer lines at the post office in mid-December. A suggestion was to notify users, and possibly ask them to space out their submissions. If LOTW can be improved for very little money, that would certainly be good. There is no need to invest significant funds to fix something that happens a couple times a year. If money is to be put into LOTW, I would hope it would result in some benefit to users, such as only needing a single log upload for contests, rather than the present two uploads, one for the contest and one for LOTW. Note also that one friend works in a closely related field, and sent the following: 1) As long as the LoTW system doesn't crumple on itself under load, I see these delays as "a good problem to have" because they show high usage, which means LoTW is successful (duh). CQWW is probably the only time of year when the system is really taxed, though there may be other windows when it is as well. It seems that this delay issue has been a problem for years, and unless there are heroics I don't know about to keep the system running during and after these events, I'm not sure it needs a solution currently. 2) I don't know how the system is architected today, or where it lives, but I know how I would design it to run on AWS. A lot of the "getting from here to there" would depend on how it's designed today. This is an ideal application for auto-scaling, as others have observed. AWS can do auto-scaling on a schedule or based on load. Either would work in this case, as long as LoTW is not running on Windows (too slow to scale). If it is on Windows (shudder), then scheduled scaling would be better. Moving the parts to AWS and implementing auto-scaling requires that the servers are stateless (don't store any state information on the servers--only in the database), and that is often not the case for old designs. I would be happy to have a design discussion with anyone who might be interested. This is the type of thing I do as part of my job as a solutions architect at AWS. I don't know who runs IT (and/or LoTW) at HQ, or on behalf of ARRL, but I'd be happy to be part of the solution if one is deemed necessary. If anyone connected with staff is interested, I'll be happy to connect him with you. He has a strong connection to ARRL, before anyone on this reflector was involved with ARRL management or direction. LOTW delays are not a critical problem. 73, Dick, N6AA
I uploaded my CQWW CW LoTW info on Tuesday morning, and the wait time was zero. I agree with Dick that this is more of a member education issue. BTW, the quantity of CQWW CW logs I saw posted on the 3830scores.com website was pretty staggering. This was the first major contest with a SFI number above 100 in a few years, and it brought out everybody. Of course, it was MUCH better for the East coast guys that for us here in the "propagation dead zone", but still better than I've seen here in quite a while..... 73; Mike W7VO
On 12/03/2020 11:08 AM Richard Norton via arrl-odv <arrl-odv@reflector.arrl.org> wrote:
Asked a number of my contesting friends about the LOTW delays after CQWW CW. None of them are upset about it.
The delay is not unexpected. One comment was that it isn't unusual for there to be longer lines at the post office in mid-December.
A suggestion was to notify users, and possibly ask them to space out their submissions.
If LOTW can be improved for very little money, that would certainly be good. There is no need to invest significant funds to fix something that happens a couple times a year.
If money is to be put into LOTW, I would hope it would result in some benefit to users, such as only needing a single log upload for contests, rather than the present two uploads, one for the contest and one for LOTW.
Note also that one friend works in a closely related field, and sent the following:
1) As long as the LoTW system doesn't crumple on itself under load, I see these delays as "a good problem to have" because they show high usage, which means LoTW is successful (duh). CQWW is probably the only time of year when the system is really taxed, though there may be other windows when it is as well. It seems that this delay issue has been a problem for years, and unless there are heroics I don't know about to keep the system running during and after these events, I'm not sure it needs a solution currently.
2) I don't know how the system is architected today, or where it lives, but I know how I would design it to run on AWS. A lot of the "getting from here to there" would depend on how it's designed today. This is an ideal application for auto-scaling, as others have observed. AWS can do auto-scaling on a schedule or based on load. Either would work in this case, as long as LoTW is not running on Windows (too slow to scale). If it is on Windows (shudder), then scheduled scaling would be better. Moving the parts to AWS and implementing auto-scaling requires that the servers are stateless (don't store any state information on the servers--only in the database), and that is often not the case for old designs.
I would be happy to have a design discussion with anyone who might be interested. This is the type of thing I do as part of my job as a solutions architect at AWS. I don't know who runs IT (and/or LoTW) at HQ, or on behalf of ARRL, but I'd be happy to be part of the solution if one is deemed necessary.
If anyone connected with staff is interested, I'll be happy to connect him with you. He has a strong connection to ARRL, before anyone on this reflector was involved with ARRL management or direction.
LOTW delays are not a critical problem.
73,
Dick, N6AA
_______________________________________________ arrl-odv mailing list arrl-odv@reflector.arrl.org https://reflector.arrl.org/mailman/listinfo/arrl-odv
Great feedback Dick. You bring up one of my long time bugaboos: I believe that ALL log submissions should be submitted directly into LoTW once accepted for credit in a contest. I’d love to speak with your member. The notion to move into the cloud and utilizing variable horsepower (AWS or whatever) is exactly what we are thinking. Please shoot me an email. Thanks! David From: arrl-odv <arrl-odv-bounces@reflector.arrl.org> On Behalf Of Richard Norton via arrl-odv Sent: Thursday, December 3, 2020 2:08 PM To: arrl-odv <arrl-odv@arrl.org> Subject: [arrl-odv:31433] LOTW Delays After CQWW CW Asked a number of my contesting friends about the LOTW delays after CQWW CW. None of them are upset about it. The delay is not unexpected. One comment was that it isn't unusual for there to be longer lines at the post office in mid-December. A suggestion was to notify users, and possibly ask them to space out their submissions. If LOTW can be improved for very little money, that would certainly be good. There is no need to invest significant funds to fix something that happens a couple times a year. If money is to be put into LOTW, I would hope it would result in some benefit to users, such as only needing a single log upload for contests, rather than the present two uploads, one for the contest and one for LOTW. Note also that one friend works in a closely related field, and sent the following: 1) As long as the LoTW system doesn't crumple on itself under load, I see these delays as "a good problem to have" because they show high usage, which means LoTW is successful (duh). CQWW is probably the only time of year when the system is really taxed, though there may be other windows when it is as well. It seems that this delay issue has been a problem for years, and unless there are heroics I don't know about to keep the system running during and after these events, I'm not sure it needs a solution currently. 2) I don't know how the system is architected today, or where it lives, but I know how I would design it to run on AWS. A lot of the "getting from here to there" would depend on how it's designed today. This is an ideal application for auto-scaling, as others have observed. AWS can do auto-scaling on a schedule or based on load. Either would work in this case, as long as LoTW is not running on Windows (too slow to scale). If it is on Windows (shudder), then scheduled scaling would be better. Moving the parts to AWS and implementing auto-scaling requires that the servers are stateless (don't store any state information on the servers--only in the database), and that is often not the case for old designs. I would be happy to have a design discussion with anyone who might be interested. This is the type of thing I do as part of my job as a solutions architect at AWS. I don't know who runs IT (and/or LoTW) at HQ, or on behalf of ARRL, but I'd be happy to be part of the solution if one is deemed necessary. If anyone connected with staff is interested, I'll be happy to connect him with you. He has a strong connection to ARRL, before anyone on this reflector was involved with ARRL management or direction. LOTW delays are not a critical problem. 73, Dick, N6AA
Hi Dick, The delays in my opinion aren’t the problem, so I agree there. The problems I see are: Visible end user facing errors. It’s a negative feedback loop where (some) users will continue to pound away because they think hitting refresh (or equivalent action) will “fix” the problem. Loss of trust that the data was actually uploaded if they experience errors or delays. That said, I’m a believer in “buy once, cry once” and while a robust system will cost us money, it will pay dividends in terms of user trust and reputation of our brand. 73 Ria N2RJ On Thu, Dec 3, 2020 at 2:08 PM Richard Norton via arrl-odv < arrl-odv@reflector.arrl.org> wrote:
Asked a number of my contesting friends about the LOTW delays after CQWW CW. None of them are upset about it.
The delay is not unexpected. One comment was that it isn't unusual for there to be longer lines at the post office in mid-December.
A suggestion was to notify users, and possibly ask them to space out their submissions.
If LOTW can be improved for very little money, that would certainly be good. There is no need to invest significant funds to fix something that happens a couple times a year.
If money is to be put into LOTW, I would hope it would result in some benefit to users, such as only needing a single log upload for contests, rather than the present two uploads, one for the contest and one for LOTW.
Note also that one friend works in a closely related field, and sent the following:
*1) As long as the LoTW system doesn't crumple on itself under load, I see these delays as "a good problem to have" because they show high usage, which means LoTW is successful (duh). CQWW is probably the only time of year when the system is really taxed, though there may be other windows when it is as well. It seems that this delay issue has been a problem for years, and unless there are heroics I don't know about to keep the system running during and after these events, I'm not sure it needs a solution currently.*
*2) I don't know how the system is architected today, or where it lives, but I know how I would design it to run on AWS. A lot of the "getting from here to there" would depend on how it's designed today. This is an ideal application for auto-scaling, as others have observed. AWS can do auto-scaling on a schedule or based on load. Either would work in this case, as long as LoTW is not running on Windows (too slow to scale). If it is on Windows (shudder), then scheduled scaling would be better. Moving the parts to AWS and implementing auto-scaling requires that the servers are stateless (don't store any state information on the servers--only in the database), and that is often not the case for old designs.*
*I would be happy to have a design discussion with anyone who might be interested. This is the type of thing I do as part of my job as a solutions architect at AWS. I don't know who runs IT (and/or LoTW) at HQ, or on behalf of ARRL, but I'd be happy to be part of the solution if one is deemed necessary.*
If anyone connected with staff is interested, I'll be happy to connect him with you. He has a strong connection to ARRL, before anyone on this reflector was involved with ARRL management or direction.
LOTW delays are not a critical problem.
73,
Dick, N6AA
_______________________________________________ arrl-odv mailing list arrl-odv@reflector.arrl.org https://reflector.arrl.org/mailman/listinfo/arrl-odv
participants (4)
-
Michael Ritz -
Minster, David NA2AA (CEO) -
Richard Norton -
rjairam＠gmail.com