All times in seconds. Benchmarks are given as two numbers separated by a slash, which are mean and standard deviation.
I’ve listed all regions, to give a sense of the overall picture.
| Region | Node | Notes |
|---|---|---|
| af-south-1 | Nothing out of the ordinary. | |
| ap-east-1 | dc2.large | Disk read-write has a large sd, 4.39/3.07. Previous benchmark, 3.25/0.06. |
| ap-east-1 | ra3.xlplus | Disk read-write has a large sd, 3.38/2.43. Previous benchmark, 2.40/0.01. |
| ap-northeast-1 | Nothing out of the ordinary. | |
| ap-northeast-2 | dc2.large | Disk read-write has a large sd, 4.49/3.03. Previous benchmark, 3.42/0.24. |
| ap-northeast-3 | dc2.large | Disk read-write has a large sd, 4.43/3.01. Previous benchmark, 3.29/0.10. |
| ap-south-1 | ra3.xlplus | Disk read-write has a large sd, 3.46/2.49. Previous benchmark slow, but before that, 2.46/0.03. |
| ap-southeast-1 | ra3.xlplus | Disk read-write has a large sd, 3.47/2.54. Previous benchmark, 2.45/0.06. |
| ap-southeast-2 | Nothing out of the ordinary. | |
| ap-southeast-3 | dc2.large | Disk read-write has a large sd, 4.41/3.09. Previous benchmark, 3.38/0.22. |
| ap-southeast-3 | ra3.xlplus | Disk read-write has a large sd, 3.38/2.44. Previous benchmark, 2.47/0.01. |
| ca-central-1 | dc2.large | Disk read-write has a large sd, 4.44/3.10. Previous benchmark, 3.21/0.04. |
| ca-central-1 | ra3.xlplus | Disk read-write has a large sd, 3.41/2.52. Previous benchmark slow, but before that, 2.51/0.03. |
| eu-central-1 | dc2.large | Disk read-write has a large sd, 4.65/3.02. Previous benchmark slow, before that 3.25/0.07. |
| eu-central-1 | ra3.xlplus | Disk read-write has a large sd, 4.40/3.03. Previous two benchmark slow, before that, 2.53/0.03. |
| eu-north-1 | Nothing out of the ordinary. | |
| eu-south-1 | dc2.large | Disk read-write has a large sd, 4.60/2.92. Previous two benchmark slow, before that 3.22/0.03. |
| eu-south-1 | ra3.xlplus | Disk read-write has a large sd, 3.43/2.51. Previous two benchmark slow, before that, 2.40/0.01. |
| eu-west-1 | ra3.xlplus | Disk read-write has a large sd, 3.47/2.53. Previous benchmark slow, before that 2.56/0.02. |
| eu-west-2 | ra3.xlplus | Disk read-write has a large sd, 3.49/2.51. Previous benchmark 2.47/0.06. |
| eu-west-3 | dc2.large | Disk read-write has a large sd, 4.49/3.04. Previous benchmark 3.46/0.22. |
| me-south-1 | Nothing out of the ordinary. | |
| sa-east-1 | dc2.large | Disk read-write has a large sd, 4.45/3.07. Previous benchmark 3.34/0.22. |
| sa-east-1 | ra3.xlplus | Disk read-write has a large sd, 3.46/2.55. Previous benchmark 2.46/0.02. |
| us-east-1 | rc2.large | Nothing out of the ordinary. |
| us-east-2 | dc2.large | Disk read-write has a large sd, 4.45/3.05. Previous benchmark slow, before that 3.32/0.11. |
| us-east-2 | ra3.xlplus | Disk read-write has a large sd, 3.48/2.54. Previous three benchmark slow, before that 2.38/0.01. |
| us-west-1 | dc2.large | Disk read-write has a large sd, 4.47/3.06. Previous four benchmark slow, before that 3.27/0.10. |
| us-west-1 | ra3.xlplus | Disk read-write has a large sd, 3.47/2.50. Previous four benchmark slow, before that 2.45/0.03. |
| us-west-2 | Nothing out of the ordinary. |
A lot of regions having, and in some cases having had now for some benchmarks (which are fortnightly) problems with the disk-read-write benchmark.
https://www.redshift-observatory.ch/cross_region_benchmarks/index.html
I misunderstood how Serverless billing works. Having read the documentation, I understood - incorrectly - that pricing was per-query. The docs talk about pricing being per RPU-hour, but billed on a per-second basis, where if a query runs for less than 60 seconds, it is billed for 60 seconds, and this is for a serverless product. Therefore pricing is per-query - as it is with Athena, and with Lambda.
In fact, it is not. Pricing is per workgroup-second. I still have not found this stated in the docs; I was pointed to a re:Invent talk where an AWS developer presented a slide which made this clear.
When I was working on the investigation, I was always running a single query at a time, so billing looked right. This change fundamentally changes the pricing proposition offered by Serverless; the original pricing conclusion was incorrect by an order of magnitude.
I have now rewritten the content regarding billing and have republished. The abstract below is the new abstract. The revision history explains what happened. Credits will credit the reader who pointed the issue out, once they let me know if they want a credit or not.
Redshift Serverless is not serverless. A workgroup is a
normal, ordinary Redshift cluster. All workgroups are initially created
as a 16 node cluster with 8 slices per node, which is the default 128
RPU workgroup, and then elastic resized to the size specified by the
user. This is why the original RPU range is 32 to 512 in units of 8 and
the default is 128 RPU; the default is the mid-point of a 4x elastic
resize range, and a single node, the smallest possible change in cluster
size, is 8 RPU/slices. 1 RPU is 1 slice. With elastic rather than
classic resize, the greater the change in either direction from the size
of the original cluster, the more inefficiency is introduced into the
cluster. As a cluster becomes increasingly larger, it becomes
increasingly computationally inefficient (the largest workgroup has 128
normal data slices, but 384 of the lesser compute slices), and
increasingly under-utilizes disk parallelism. As a cluster becomes
increasingly smaller, it becomes increasingly computationally
inefficient (each data slice must process multiple slices’ worth of
data), and incurs increasingly more disk use overhead with tables. The
more recently introduced smaller workgroups, 8 to 24 RPU (inclusive both
ends) use a 4 slice node and have two nodes for every 8 RPU. In this
case, the 8 RPU workgroup is initially a 16 node cluster with 8 slices
per node, which is resized to a 2 node cluster with 4 slices per node -
a staggering 16x elastic resize; the largest resize permitted to normal
users is 4x; an 8 RPU workgroup, with small tables, uses 256mb per
column rather than the 16mb per column of a native two node cluster.
Workgroups have a fixed number of RPU and require a resize to change
this; workgroups do not dynamically auto-scale RPUs. I was unable to
prove it, because AutoWLM is in the way, but I am categorically of the
view that the claims made for Serverless for dynamic auto-scaling are
made on the basis of the well-known and long-established mechanisms of
AutoWLM and Concurrency Scaling Clusters (“CSC”). Finally, it is
possible to confidently extrapolate from the ra3.4xlarge
and ra3.16xlarge node types a price as they would be in a
provisioned cluster for the 8 slice node type, of 6.52 USD per hour.
Both Provisioned and Serverless clusters charge per node-second, but
Serverless goes to zero cost with zero use. With the default Serverless
workgroup of 128 RPU/16 nodes (avoiding the need to account for the
inefficiencies introduced by elastic resize), one hour of constant use
(avoiding the need to account for the Serverless minimum query charge of
60 seconds of run-time), without CSC (avoiding the question of how
AutoWLM will behave), costs 46.08 USD. A Provisioned cluster composed of
the same nodes costs 104.32 USD; about twice as much. Here we have to
take into consideration the inefficiencies introduced by elastic resize,
which become more severe the more the cluster deviates from 16 NRPU,
that Serverless uses AutoWLM, with all its drawbacks, and which is a
black box controlling the use of CSC, with each CSC being billed at the
price of the workgroup, and the 60 second minimum charge. All Serverless
costs (including the charge for Redshift Spectrum S3 access) have been
rolled into a single AWS charge for Serverless, so it is not possible to
know what is costing money. It would have been much better if AWS had
simply introduced zero-zero billing on Provisioned clusters. This would
avoid many of the weaknesses and drawbacks of Serverless Redshift, which
wholly unnecessarily devalue the Serverless product, as well as avoiding
the duplicity, considerable added complexity, end-user confusion, cost
in developer time and induced cluster inefficiency involved in the
pretence that Serverless is serverless.
I bought an air quality monitor, which measures CO2, and I now know the sleepiness I have at times felt during the day, which for decades I assumed was simply being tired, is in fact carbon dioxide narcosis.
I now have the window in my room open always, day and night.
A week ago, an open source hardware and open source software air quality monitor, AirGradient, arrived in the post.
Some time ago, there was a HackerNews post where a developer was travelling to an expo and wanted to gauge his Covid risk, which he did by measuring CO2 levels, on the basis that the level of CO2 would indicate how many other people were in the vicinity.
His findings were fascinating, and also made me aware of CO2 levels in general, that they mattered (not for Covid, but in and of themselves, for their influence on human physiology), and that they could be measured.
Then, also via HackerNews, I came to know about AirGradient.
I had already Googled for CO2 monitors, but found a wide range, and also run into the question of calibration, which complicated matters.
AirGradient answered all these questions - I was confident in the quality and correctness of their product, their hardware choices, and the device is available at a reasonable price (about 130 USD).
I made the purchase, the unit was sent from Thailand, and in the UK, I paid no import duty or taxes (I suspect due to the UK Gov having since Brexit suspended a whole bunch of import bureaucracy, to lessen the effect of Brexit on imports - my imports from the USA are also attracting no tax or charges, when I am certain they ought to be).
There are actually a couple of variants of the device, basic or pro, indoor or outdoor, and pre-soldered or requires-soldering. If you purchase the kit which requires soldering, it’s cheaper. There’s no way in a zillion years I would solder anything, so I just paid up another 50 USD or so and bought the pre-soldered unit.
Note that with the pre-soldered unit you will need to do just a little assembly - there are four chips, in anti-static bags, which you need to fit into their sockets - so, literally, pushing the legs of a chip into the plastic socket which receives the legs - and then you need to screw the two halves of the plastic case together.
The on-line instructions for this are not great - a case of quantity over quality - if people start to get interested, I’ll take my unit apart and post some photos and a guide.
Once assembled, you then need to flash the firmware.
On Windows, easy. Plug the device into a USB socket, go to the AirGradient web-site, click a button on the web-page. Done.
On Linux, ho ho ho. Install and configure the Arduino development environment, downloaded all the necessary sources and libraries, build and flash. The instructions are 95% correct, and I did this. I would suggest it is much quicker and easier to collar a friend with a Windows machine and just do it there.
When you start the device, there’s 60 seconds in which you can connect to a wifi hotspot it offers, and it will begin sending data to you - I don’t know exactly what this means, as I’ve not tried to use it. Maybe you cURL, or maybe it offers a web-site, no idea. With this though the idea is you can log data on an ongoing basis.
The device has an OLED display, which shows the current readings from the sensors, and that’s what I use.
So, now we’re up and running.
First thing to realize is that the CO2 sensor is not calibrated. It auto-calibrates, once per week; it takes the lowest reading it has seen each week, and regards that as 420 PPM (the natural level of CO2).
My unit was about 350 PPM off the mark, under-reporting, until it calibrated. I knew this because with the window open, and me not in it, my room drops down to the background level, and the device was reporting about 60 or 70 PPM.
Then one day, while I was watching, I saw the reported CO2 level shoot up over a few measurements, by that missing 350 PPM - auto-calibration had occurred.
The other sensors do not need calibration.
The sensors are;
With VOC, there’s no way to differentiate between harmful and harmless - what you have is a measurement - it’s up to you to judge based on your knowledge of the environment.
For me, the PM2.5, VOC and NOX levels have always been low (although VOC does vary a fair bit - from 1 up to 250 or so, and it’s not really clear to me why).
The really interesting and consequential measurement is for CO2.
Now, if you first power up your unit in your computing room, and no windows are open, you’ll see a value likely on the order of a few thousand PPM, and you’ll think the sensor must be way off.
It’s not.
The background level is 420 PPM. The recommended max for good quality air seems to be 600 PPM.
When I close the windows in my room, the CO2 rises rapidly and steadily - after maybe 15 minutes I’m looking at about 1500 PPM, and it just keeps climbing. CO2 rises quickly. Note I work in small room, though, about 100m3 (cubic, since we’re interested here in volume). Bigger rooms will take longer, but given how quickly CO2 rises for me at 100m3, having a room a few times larger just won’t change much. It’ll take you an hour where it might take me 15 minutes.
If I leave the window closed overnight, in the morning, I’m just under 5000 PPM.
During the day, if I’m sleepy and CO2 is at or over something like 1500, I’m sleepy because of CO2.
Opening the window, that sleepiness (which in fact is really wooziness) goes away, as quickly as it takes the incoming air to flush the room, which is a couple of minutes.
If I’m in my room with the window open, CO2 is about 500 PPM - that extra 80 is me. If I leave the room, it drops to 420.
I’m now aware of what CO2 narcosis feels like in my body - it’s like feeling faintly sick.
I no longer need to sensor to know it is occurring - although starting to fall asleep for no reason at all is a strong hint :-)
I’m also thinking that when I sleep, which is to say, resting and repairing and so on, surely my body is going to want not to be saturated with excess CO2 all night long; I now sleep with the window open, which means another quilt and so on.
All times in seconds, and are mean/std-dev.
Regions with no node/notes have nothing going on. They’re present to provide the full picture.
| region | node | notes |
|---|---|---|
| af-south-1 | ||
| ap-east-1 | dc2.large | The disk-read-write benchmark is back to normal. |
| ap-east-1 | ra3.xlplus | The disk-read-write benchmark is back to normal. |
| ap-northeast-1 | ||
| ap-northeast-2 | dc2.large | The disk-read-write benchmark is back to normal. |
| ap-northeast-2 | ra3.xlplus | The disk-read-write benchmark is slow; 3.39/2.46, previously 2.54/0.05. |
| ap-northeast-3 | ra3.xlplus | The disk-read-write benchmark is back to normal. |
| ap-south-1 | ra3.xlplus | The disk-read-write benchmark remains slow. |
| ap-southeast-1 | ra3.xlplus | The disk-read-write benchmark is back to normal. |
| ap-southeast-2 | ||
| ap-southeast-3 | dc2.large | The disk-read-write benchmark is back to normal. |
| ap-southeast-3 | ra3.xlplus | The disk-read-write benchmark is back to normal. |
| ca-central-1 | dc2.large | The disk-read-write benchmark remains slow. |
| ca-central-1 | ra3.xlplus | The disk-read-write benchmark remains slow. |
| eu-central-1 | dc2.large | The disk-read-write benchmark remains slow. |
| eu-central-1 | ra3.xlplus | The disk-read-write benchmark remains slow. |
| eu-north-1 | ||
| eu-south-1 | dc2.large | The disk-read-write benchmark remains slow. |
| eu-south-1 | ra3.xlplus | The disk-read-write benchmark remains slow. |
| eu-west-1 | ra3.xlplus | The disk-read-write benchmark remains slow. |
| eu-west-2 | ra3.xlplus | The disk-read-write benchmark is back to normal. |
| eu-west-3 | dc2.large | The disk-read-write benchmark is back to normal. |
| me-south-1 | ||
| sa-east-1 | dc2.large | The disk-read-write benchmark remains slow. |
| sa-east-1 | ra3.xlplus | The disk-read-write benchmark remains slow. |
| us-east-2 | dc2.large | The disk-read-write benchmark is back to normal. |
| us-east-2 | ra3.xlplus | The disk-read-write benchmark remains slow. |
| us-west-1 | dc2.large | The disk-read-write benchmark remains slow. |
| us-west-1 | ra3.xlplus | The disk-read-write benchmark remains slow. |
| us-west-2 | dc2.large | The disk-read-write benchmark is slow; 4.35/3.05, previously 3.61/0.32. |
https://www.redshift-observatory.ch/cross_region_benchmarks/index.html
I had cause today to attempt to purchase a security fast-track ticket for Manchester Airport.
When you come to purchase a ticket, you select a date and a time.
The time is described as “entry time”.
This I guess means the time you enter security - so you need to decide how long before your flight you will enter - and available times are in 15 minute blocks.
I pick a date and time, and add the ticket to the cart.
In the cart, the time for the ticket is always 30 minutes after the time I have chosen.
I’m trying to get 10am. If I select 10am, the ticket is 10.30am. If I select 9.30am, I get 10am.
I’m now not confident in my purchase, so I phone the airport.
Manchester Airport has the worst and most drawn out menu system I’ve met in a very, very long time. It also is arranged so that it leads you to inadvertently loop, and go back to the beginning of the menu system.
It took me 5.5 minutes of listening to drivel about Manchester Airport to get into the queue for fast-track tickets.
I spoke to a young lady.
She informed me the entry window is in fact two hours (I did not find this on the Manchester Airport site, and even now I know it, I still cannot find it).
I explained to her the problem with ticket times, and while we were talking, I found a link to the Fast-Track FAQ page which was broken.
She will inform her manager, who will inform someone else, who will do I don’t know what.
I asked if there was any way I could contact support. The only method is a feedback form, which takes up to ten days for a reply.
End of conversation.
I proceeded to purchase a ticket - it’s only 6 GBP, so if it goes wrong, not the end of the world - with the selected time being 30 minutes before the time I actually wish for, to get the ticket I actually wish for.
Upon the purchase going through, you are instantly distracted and diverted from the task in hand, by an advert, which greys out the page, which claims to off 16.87 GBP in cashback. In the small print, “this offer costs 15 GBP per month”.
Interruptive adverts and offers are a problem normally, but especially so during a process which requires concentration, and the offer is shameful.
I rather suspect it would have taken less time to take the normal security track, than purchase the fast-track ticket; I’ve been working on this for about 30 minutes now. At least it will save me carrying a bag, while I queue.
(Addnedum. Having purchased, a PDF is sent, which is the ticket. It has a header, a banner image. That image is missing. The edge of the box of where it should be is present, and the missing filename is present in the box.)
This is a bit by-the-by.
I’m in the UK ATM.
I’ve been taking trains twice a week.
I’ve come to understand that buying tickets on-line is always correct, because buying tickets in the station can mean you get burned.
I’m on a train now - I looked at the ticket price on-line, it was 6.70 GBP.
I hadn’t much time, so I thought to buy in the station, it’s quicker than on-line.
In the station, I had to pay 14.50 GBP.
I can see absolutely no reason for it, and so I consider it hostile and have adjusted my views, expectations and behaviour accordingly.
I should note also the train offers 15 minutes of wifi only unless you register, but I will not hand over my ID and being tracked in order to get wifi. This also is hostile behaviour.
(And I can think back to a remarkable experience a year ago with another UK train service, of pervasive incompetence, apathy and hostility to the care and interests of customers. Their on-line ticket ordering was flawed, so I could not collect my ticket, and the refund process was to my eye designed to prevent refunds. After a full year of often ridiculous dialogue, where customer support were not reading what was written or comprehending what had happened and were talking past me, I gave up, wrote up and published what had happened, and wrote them off.)
As an aside, I have very recently resolved to learn to drive, to obtain an alternative means of transport. Flying is and has for a long time been stressful and unpleasant, long distance rail is impossible because of the lack of reliability for making connections and the lack of compensation in the event of missed connections, and local rail not forming a positive impression. It’s not a great surprise - any and all large organizations offer poor service and customer service; they have no idea what customers experience, and no capacity to respond, even if they knew.
In the end, you can rely on yourself.
Home 3D Друк Blog Bring-Up Times Consultancy Cross-Region Benchmarks Email Forums IRC Mailing Lists Reddit Redshift Price Tracker Redshift Version Tracker Redshift Workbench System Table Tracker The Known Universe Twitter White Papers