Amazon's Policy Violation #56
Comments
|
By default the timers are all set to a time that should not cause any PRE's. Panda timer is at 1 second, search timer is at 950ms and queue timer is at 2 seconds. It seems Amazon has different PRE settings for those 3 pages. If Amazon notices a high frequency lookup they send a PRE. The script shows how many PRE's it gets on the panda page and the search page. The script has a built in limit for any timer and won't let the user set the timer below 700ms. Like Amazon has said, the user is responsible to make sure they don't get a lot of PRE's which is Amazon's first warning of a problem. You can get a lot of PRE's if you are using another script at the same time or lowered the timers too low. A few PRE's should be OK but if you are getting hundreds then that could be a problem. Raise the timers until you don't get any more PRE's. I don't know at what point Amazon would find a problem so keep those PRE's at 0 as much as you can. |
|
Is it possible for me to receive Pres without Panda Crazy showing it?
Thanks for replying, sorry for bothering you
Em qua, 26 de jan de 2022 11:11, JohnnyRS ***@***.***>
escreveu:
… By default the timers are all set to a time that should not cause any
PRE's. Panda timer is at 1 second, search timer is at 950ms and queue timer
is at 2 seconds. It seems Amazon has different PRE settings for those 3
pages. If Amazon notices a high frequency lookup they send a PRE. The
script shows how many PRE's it gets on the panda page and the search page.
The script has a built in limit for any timer and won't let the user set
the timer below 700ms.
Like Amazon has said, the user is responsible to make sure they don't get
a lot of PRE's which is Amazon's first warning of a problem. You can get a
lot of PRE's if you are using another script at the same time or lowered
the timers too low. A few PRE's should be OK but if you are getting
hundreds then that could be a problem. Raise the timers until you don't get
any more PRE's. I don't know at what point Amazon would find a problem so
keep those PRE's at 0 as much as you can.
—
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXKS4RRK7KW3C6QVRWAIQF3UX76IXANCNFSM5M3B6HLA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I would say it is very unlikely that the script wouldn't detect a PRE especially if Amazon is sending a lot of them. If using two scripts then there is a chance the other script is getting more PRE's than this script so the number wouldn't be accurate but it should be showing some at the top. |
|
Sorry to bother you again. Just one more question, please. When Amazon says
that frequent calls are prohibited, in this case it is referring to Scripts
that give a lot of Pres, right? Or even if I configure a Script like Panda
Crazy to call Amazon every 3 seconds, Does Amazon consider this to be
calling it at high frequency? Is it possible to know how long a Script must
call Amazon to not be considered something that calls Amazon in high
frequency?
Em qua, 26 de jan de 2022 12:10, JohnnyRS ***@***.***>
escreveu:
… I would say it is very unlikely that the script wouldn't detect a PRE
especially if Amazon is sending a lot of them. If using two scripts then
there is a chance the other script is getting more PRE's than this script
so the number wouldn't be accurate but it should be showing some at the top.
—
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXKS4RXW5ZPAUYNA6NVETVTUYAFHHANCNFSM5M3B6HLA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Amazon hasn't defined what would be called a high frequency that I know of. The PRE is our best way of knowing if it's too fast or fine. From my observations, panda calls get no PRE's at 1 second and search page calls get no PRE's at 1 second too. That is the default I set in the script. You may find the search page timer could be lower than 1 second though. Think about PRE as a warning but not as a violation. Getting over 1000 PRE's a day probably would be extreme but a few hundred a day may not be. Amazon has not said how many PRE's a day would be a violation so best to not get any PRE's and not worry about it. |
|
Okay. Thanks for the answer and patience. God bless you
Em qui, 27 de jan de 2022 20:32, JohnnyRS ***@***.***>
escreveu:
… Amazon hasn't defined what would be called a high frequency that I know
of. The PRE is our best way of knowing if it's too fast or fine. From my
observations, panda calls get no PRE's at 1 second and search page calls
get no PRE's at 1 second too. That is the default I set in the script. You
may find the search page timer could be lower than 1 second though. Think
about PRE as a warning but not as a violation. Getting over 1000 PRE's a
day probably would be extreme but a few hundred a day may not be. Amazon
has not said how many PRE's a day would be a violation so best to not get
any PRE's and not worry about it.
—
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXKS4RRE7LC7YNQQ2W7V22DUYHIY5ANCNFSM5M3B6HLA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Amazon does not offer an API interface for workers. The documentation does not list throttle rates that trigger a slow down request (HTTP 429 response). My guess is that the AWS servers determine a value based on their server load. I keep a steady 24/7 and have not had issues. I will notice 15-50 429 responses come up in a short 5-10 minute period. But then nothing for another week. My interpretation of the AUP has always been that Amazon is looking to prevent workers from purposely flooding the network to prevent other workers from grabbing HITs or from requesters from getting their batches done. I do not really see it as being an issue with PMAX for two reasons.
Who came up with labeling them as a PRE response and not a 429? |
Does panda Crazy violate this Amazon usage policy?
I mean this policy: do not disrupt or harm the operation of the site or the integrity of the market (eg scripts and automation tools that call MTurk continuously and at high frequency are not OK). As a result, we will have to make hard calls from time to time when we notice unusual activity on the account resulting from a specific automation tool or script. Remember that you are responsible for any script or automation tool you use with MTurk, and your use of an automation script or tool is at your own risk.
The text was updated successfully, but these errors were encountered: