
On Fri, Sep 9, 2016 at 10:25 PM, Russell Coker via luv-main < luv-main@luv.asn.au> wrote:
The LUV server has just been down for a few hours.
It all started a couple of weeks ago when I wrote a Mon plugin for running lm-
...
Now I think that everything is fine. Email me off-list if you notice any problems.
+1 on the excellent report. <rant> Better than the crap one usually sees from commercial services "There's an issue affecting a really tiny PERCENTAGE of our HUGE customer base" ... "The issue is being examined" ... "The issue has been resolved, we value your custom, your call is important to us, batteries not included, free unicorn to the first 50 callers, we are AWESOME!" It's almost worthless getting service updates from some commercial services for all the useless waffle they usually have </rant>

On Saturday, 10 September 2016 3:40:56 PM AEST Anthony via luv-main wrote:
Now I think that everything is fine. Email me off-list if you notice any problems.
+1 on the excellent report.
I'm glad you appreciate it.
<rant> Better than the crap one usually sees from commercial services "There's an issue affecting a really tiny PERCENTAGE of our HUGE customer base" ... "The issue is being examined" ... "The issue has been resolved,
People who work for commercial ISPs generally feel unable to admit error, that significantly reduces their ability to write a good report. LUV is not paying anything for the service and is relying on me and others donating time to running it so no-one is going to complain much about occasional minor mistakes. Having a bad entry in /etc/fstab isn't the smartest thing to do, but it's also not that much of a big deal. I got all the data transferred out of VPAC well before it shut down, so I avoided problems that could potentially have caused significant data loss... As an aside it would be nice if there was a way of validating some of the various files that are essential for booting successfully. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Russell Coker via luv-main <luv-main@luv.asn.au> writes:
<rant> Better than the crap one usually sees from commercial services "There's an issue affecting a really tiny PERCENTAGE of our HUGE customer base" ... "The issue is being examined" ... "The issue has been resolved,
People who work for commercial ISPs generally feel unable to admit error, that significantly reduces their ability to write a good report.
Another problem is the perception - that unfortunately is partly right to some degree - that customers (even more so with media) don't care about the details as to what went wrong, they only care about how long you were offline for and how many people were inconvenienced (and in some cases how much they can sue you for). So companies issue generate press releases to try and distort the figures in their favour. Doesn't work with me, I tend to read these as "something went wrong, we don't know what, it could happen again, but everything is working right now so everything is good". A classic example is the "signal failure" excuse that is vastly overused by Metro trains and prior companies. We rarely hear what went wrong, unless it results in being able to divert blame (rightly or wrongly) onto somebody else (e.g. possum getting electrocuted and shorting high voltage power or lightning strike). -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/

On Sunday, 11 September 2016 10:06:54 AM AEST Brian May via luv-main wrote:
People who work for commercial ISPs generally feel unable to admit error, that significantly reduces their ability to write a good report.
Another problem is the perception - that unfortunately is partly right to some degree - that customers (even more so with media) don't care about the details as to what went wrong, they only care about how long you were offline for and how many people were inconvenienced (and in some cases how much they can sue you for). So companies issue generate press releases to try and distort the figures in their favour.
Yes.
Doesn't work with me, I tend to read these as "something went wrong, we don't know what, it could happen again, but everything is working right now so everything is good".
Me too. Another difference with LUV is that it's an organisation that's about education. Writing a detailed explanation helps achieve the goal of teaching people about Linux.
A classic example is the "signal failure" excuse that is vastly overused by Metro trains and prior companies. We rarely hear what went wrong, unless it results in being able to divert blame (rightly or wrongly) onto somebody else (e.g. possum getting electrocuted and shorting high voltage power or lightning strike).
Trains are a bit different. A large part of it is fairly simple in concept, and the details of what happens really aren't. Last year I attended an interesting lecture at RMIT by an Electrical Engineer working for the train system. Maintaining an adequate voltage on all the lines is a very difficult problem and one that isn't always solved. There are also some serious design issues that affect the quality of the service. For example if train stations were placed above shops (like Glenferrie) then kinetic energy would be converted to potential energy as the train goes uphill to the station and it would take less electrical energy to get up to speed when it leaves the station. It probably would be good if they had the occasional announcement "because residents think that a station above ground level is ugly this train will be delayed due to low voltage". -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On Sun, Sep 11, 2016 at 02:22:39PM +1000, Russell Coker via luv-main wrote:
example if train stations were placed above shops (like Glenferrie) then kinetic energy would be converted to potential energy as the train goes uphill to the station and it would take less electrical energy to get up to speed when it leaves the station.
the Montreal metro does that. https://en.wikipedia.org/wiki/Montreal_Metro the tracks drop steeply after each station and then rise again before the next (flat) platform. not sure how much it dips, but I remember it seemed like a lot. dunno why the idea isn't more widespread. maybe 'cos you need a fair sized dip. back of the envelope says you need a 14m drop to get you up to 60km/h, or 20m up to 72km/h (ideal, excluding friction etc.) mgh = 0.5mv^2 60km/h = 16.7m/s => h=14.2m, or 72km/h = 20m/s => h=20.4m with a big dip, if the train stops or slows down at the bottom then maybe it can't climb back up again...? the Montreal metro is also notable because they have rubber wheels on concrete tracks. very bouncy and noisy, but perhaps it means they can get traction on steeper slopes than steel wheels on rails. obviously the steeper you can make the gradient and the closer you can put it to the station the longer the train will be kept at maximum speed. a shallow gradient spread out between stations doesn't really help that much - you need the steepest possibly climb/drop to the station to minimise travel time. I suspect the "big dip" idea is impractical for steel wheels on (potentially) wet rails, and a small dip doesn't help all that much 'cos of the v^2 term. here's another idea. if Melb trains carried onboard storage (super-capacitors, flywheels, batteries, ...) then they could store the majority of the braking energy and deploy it from on-board storage when leaving the station rather than pulling it from the overhead power cables. presumably trains already do "re-gen" on deceleration, but currently dump it back into the (unhappy) overhead grid? electric cars are probably better than 64% efficient at re-gen these days, especially on 4wd models. https://www.tesla.com/blog/magic-tesla-roadster-regenerative-braking trains with steel wheels do better. but frankly it sounds like improving the Melb trains overhead power system would be a better idea. cheers, robin

All this talk of trains and hills reminds me of this simple explanation. Not sure how accurate it is but it has James may so it 'feels' more accurate. https://www.youtube.com/watch?v=KbUsKWbOqUU On 12/09/2016 2:51 PM, Robin Humble via luv-main wrote:
On Sun, Sep 11, 2016 at 02:22:39PM +1000, Russell Coker via luv-main wrote:
example if train stations were placed above shops (like Glenferrie) then kinetic energy would be converted to potential energy as the train goes uphill to the station and it would take less electrical energy to get up to speed when it leaves the station. the Montreal metro does that. https://en.wikipedia.org/wiki/Montreal_Metro the tracks drop steeply after each station and then rise again before the next (flat) platform. not sure how much it dips, but I remember it seemed like a lot.
dunno why the idea isn't more widespread. maybe 'cos you need a fair sized dip. back of the envelope says you need a 14m drop to get you up to 60km/h, or 20m up to 72km/h (ideal, excluding friction etc.) mgh = 0.5mv^2 60km/h = 16.7m/s => h=14.2m, or 72km/h = 20m/s => h=20.4m
with a big dip, if the train stops or slows down at the bottom then maybe it can't climb back up again...? the Montreal metro is also notable because they have rubber wheels on concrete tracks. very bouncy and noisy, but perhaps it means they can get traction on steeper slopes than steel wheels on rails.
obviously the steeper you can make the gradient and the closer you can put it to the station the longer the train will be kept at maximum speed. a shallow gradient spread out between stations doesn't really help that much - you need the steepest possibly climb/drop to the station to minimise travel time.
I suspect the "big dip" idea is impractical for steel wheels on (potentially) wet rails, and a small dip doesn't help all that much 'cos of the v^2 term.
here's another idea. if Melb trains carried onboard storage (super-capacitors, flywheels, batteries, ...) then they could store the majority of the braking energy and deploy it from on-board storage when leaving the station rather than pulling it from the overhead power cables. presumably trains already do "re-gen" on deceleration, but currently dump it back into the (unhappy) overhead grid?
electric cars are probably better than 64% efficient at re-gen these days, especially on 4wd models. https://www.tesla.com/blog/magic-tesla-roadster-regenerative-braking trains with steel wheels do better.
but frankly it sounds like improving the Melb trains overhead power system would be a better idea.
cheers, robin _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On Monday, 12 September 2016 12:51:19 AM AEST Robin Humble via luv-main wrote:
the Montreal metro does that. https://en.wikipedia.org/wiki/Montreal_Metro the tracks drop steeply after each station and then rise again before the next (flat) platform. not sure how much it dips, but I remember it seemed like a lot.
dunno why the idea isn't more widespread. maybe 'cos you need a fair sized dip. back of the envelope says you need a 14m drop to get you up to 60km/h, or 20m up to 72km/h (ideal, excluding friction etc.) mgh = 0.5mv^2 60km/h = 16.7m/s => h=14.2m, or 72km/h = 20m/s => h=20.4m
If you wanted to convert all the kinetic energy to potential energy then you would need a significant rise. But if you convert just 1/3 of it then that's enough to make a significant electricity saving and also a good improvement to start and stop times. The start and stop times are significant to the overall journey time in areas like Glenferrie where there are stations within jogging distance.
with a big dip, if the train stops or slows down at the bottom then maybe it can't climb back up again...?
As noted in the video Michael cited the maximum gradient for steel wheeled trains is quite small. But if the station is 4M above ground level (enough for shops below it) then you only need a 250M ramp at each end, that's about twice the length of a city train.
the Montreal metro is also notable because they have rubber wheels on concrete tracks. very bouncy and noisy, but perhaps it means they can get traction on steeper slopes than steel wheels on rails.
Definitely.
obviously the steeper you can make the gradient and the closer you can put it to the station the longer the train will be kept at maximum speed. a shallow gradient spread out between stations doesn't really help that much - you need the steepest possibly climb/drop to the station to minimise travel time.
I suspect the "big dip" idea is impractical for steel wheels on (potentially) wet rails, and a small dip doesn't help all that much 'cos of the v^2 term.
If you design the gradient to be half the maximum that the train can climb then that will increase accelleration by 50%. Given the very low acceleration of trains (most trains seem to have have less power per carriage than a mid sized car) that will really make a difference.
here's another idea. if Melb trains carried onboard storage (super-capacitors, flywheels, batteries, ...) then they could store the majority of the braking energy and deploy it from on-board storage when leaving the station rather than pulling it from the overhead power cables. presumably trains already do "re-gen" on deceleration, but currently dump it back into the (unhappy) overhead grid?
Trains currently put electricity back into the train grid. In the train grid they have super-capacitors to store power when more trains are braking than accellerating. It's probably more effective to have super-capacitors in the grid as they are heavy and transporting them would reuire more energy, heavier carriage chassis, and probably some safety issues.
but frankly it sounds like improving the Melb trains overhead power system would be a better idea.
There are some serious issues with that. The train company has contracts with power companies for the maximum power that they can draw. They have a maximum draw of about 100MW and changes to the load is a major issue for power stations. On Monday, 12 September 2016 3:00:22 PM AEST Michael Verrenkamp via luv-main wrote:
All this talk of trains and hills reminds me of this simple explanation. Not sure how accurate it is but it has James may so it 'feels' more accurate.
https://en.wikipedia.org/wiki/Rack_railway He makes some great points. One thing he omits is the fact that some trains have gears to allow them to climb steep slopes. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Quoting Brian May (brian@linuxpenguins.xyz):
A classic example is the "signal failure" excuse that is vastly overused by Metro trains and prior companies. We rarely hear what went wrong, unless it results in being able to divert blame (rightly or wrongly) onto somebody else (e.g. possum getting electrocuted and shorting high voltage power or lightning strike).
I'm reminded about the old British Rail gag about 'the wrong type of snow' being cited as an excuse for problems. https://en.wikipedia.org/wiki/The_wrong_type_of_snow

On Saturday, 10 September 2016 11:39:09 PM AEST Rick Moen via luv-main wrote:
I'm reminded about the old British Rail gag about 'the wrong type of snow' being cited as an excuse for problems. https://en.wikipedia.org/wiki/The_wrong_type_of_snow
https://en.wikipedia.org/wiki/Slippery_rail#Other_causes In Australia we have the wrong type of millipedes! LOL. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On 11.09.2016 20:48, Russell Coker via luv-main wrote:
On Saturday, 10 September 2016 11:39:09 PM AEST Rick Moen via luv-main wrote:
I'm reminded about the old British Rail gag about 'the wrong type of snow' being cited as an excuse for problems. https://en.wikipedia.org/wiki/The_wrong_type_of_snow
https://en.wikipedia.org/wiki/Slippery_rail#Other_causes
In Australia we have the wrong type of millipedes! LOL.
A couple of observations on failures, I have worked as a complex systems Technician for 30 years, worked in a Control room for 2 years and done unix system maintence for a number of local ISP's, There would be few staff in management or public relations who would have any kind of detailed technical understanding. This particularly applies to railway signalling and power supply, both which are very complex, detailed explanations would end up being garbled and therefore of little use. So when as a technician you report something that will end up as a media report you just give a simple basic report, anything else will cause problems. If any management require a detailed report you of course do so, but public relations will rarely if ever ask for such a report. Lindsay

On 11.09.2016 20:48, Russell Coker via luv-main wrote:
On Saturday, 10 September 2016 11:39:09 PM AEST Rick Moen via luv-main wrote:
I'm reminded about the old British Rail gag about 'the wrong type of snow' being cited as an excuse for problems. https://en.wikipedia.org/wiki/The_wrong_type_of_snow
https://en.wikipedia.org/wiki/Slippery_rail#Other_causes
In Australia we have the wrong type of millipedes! LOL.
The grade trains can climb is governed by the coeffecient of static friction of steel on steel which is aprox 0.33, ie a trains tractive effort is aprox 1/3rd of the vehicles weight. The maximum grade normally encountered on adhesive railways is around 1 in 16. The load pulled on this sort of grade would be around 3 times the engines weight. The maximum grade currently on Victorian lines is 1 in 30 encountered between Upper Ferntree gully and Upwey, also on the Puffing Billy line from Cockatoo. While some of the Melbourne trains can do regenerative braking, I have been told the rectifer stations cannot handle this so it is not used in Melbourne. The problem apparently is not enough funds availible for power supply upgrade, inspite of there being projected excellent savings can be acheived. Lindsay

On Monday, 12 September 2016 6:53:56 PM AEST Ray via luv-main wrote:
While some of the Melbourne trains can do regenerative braking, I have been told the rectifer stations cannot handle this so it is not used in Melbourne. The problem apparently is not enough funds availible for power supply upgrade, inspite of there being projected excellent savings can be acheived.
About a year ago I attended a lecture by an EE who works on the train system. He described in detail how they do regenerative braking and use super- capacitors to store the energy. Lack of money is a problem. Too much is being wasted on stupid things like FTTN which is turning out to be much more expensive than the original FTTP plan. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On Mon, Sep 12, 2016 at 1:04 PM, Russell Coker via luv-main < luv-main@luv.asn.au> wrote: [snip] Should we rename luv-main to luv-trainspotting?

On 12.09.16 13:21, Anders Holmstrom via luv-main wrote:
On Mon, Sep 12, 2016 at 1:04 PM, Russell Coker via luv-main < luv-main@luv.asn.au> wrote: [snip] Should we rename luv-main to luv-trainspotting?
Hmmm ... the little bit of OT traffic avoids us being mistaken for a dead list? Incidentally, the mention of rail service providers being (electricity) demand constrained reminds me that residential consumers are about to be exposed to "demand tariffs" too, and they can be a very good thing to avoid if you have any power hungry appliance: http://www.solarquotes.com.au/blog/victorian-residential-demand-tariffs/ That's more than far enough OT, or we'll see s/outage/outrage, I guess. Erik

On Monday, 12 September 2016 9:53:50 PM AEST Erik Christiansen via luv-main wrote:
Incidentally, the mention of rail service providers being (electricity) demand constrained reminds me that residential consumers are about to be exposed to "demand tariffs" too, and they can be a very good thing to avoid if you have any power hungry appliance:
http://www.solarquotes.com.au/blog/victorian-residential-demand-tariffs/
Interesting. I've been wondering how difficult it would be to use some IP enabled switches to control home energy use. If you had a meter on the main power that reports the power use to a Linux system then you could have it turn off non-essential devices and make your PCs stop running BOINC if power use is too high. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On 13.09.16 12:23, Russell Coker wrote:
On Monday, 12 September 2016 9:53:50 PM AEST Erik Christiansen via luv-main wrote: ...
http://www.solarquotes.com.au/blog/victorian-residential-demand-tariffs/
Interesting. I've been wondering how difficult it would be to use some IP enabled switches to control home energy use. If you had a meter on the main power that reports the power use to a Linux system then you could have it turn off non-essential devices and make your PCs stop running BOINC if power use is too high.
Something ready to go might be: https://openenergymonitor.org/emon/ if you don't mind wireless and Raspberry Pi. (If you find a more attractive product, it would be interesting to hear.) There's a tangentially related article in issue 136 (July - September 2016) of ReNew magazine (probably still in the newsagents), titled "Power without waste - Building (or buying) an efficient computer". I'm tempted by the Udoo X86, a US$89 mobo which appears to compare favourably for more general use compared to Raspberry Pi: https://www.youtube.com/watch?v=dJkHxDjFuNA The included arduino interface ought to provide a path to utilising arduino-based power measurement. ISTR that there are a couple of them out there, ... e.g. https://store.open-electronics.org/Powermeter_shield But there's nothing wrong with doing it all under Linux as suitable clamp-on measuring units seem to be available. (And the wireless hook-up is both awfully convenient and something of a safety feature.) Erik
participants (9)
-
Anders Holmstrom
-
Anthony
-
Brian May
-
Erik Christiansen
-
Michael Verrenkamp
-
Rick Moen
-
Robin Humble
-
Russell Coker
-
zlinew9@virginbroadband.com.au