Train 49 - Why Late into CHI 7/29?

Anyone know why LSL is late into Chicago for 7/29 arrival? We leave ALB tomorrow for LAX and a little worried about transfer.

These days LSL is almost always 2 to 3 hours late into Chicago due to congestion issues both on CSX and NS. Usually one is able to make the connection to the western trains. There are a few rare occasions when it is late enough to miss connection. Like today it might miss the connection to the CZ but should still make SWC. Then again all the western trains do not always leave on time either, and if it is a small miss and there are many connecting passengers they do hold the western trains to enable the connection to be made in spite of the delay.

Sigh. ..but we have some info now which is always appreciated Will keep our hopes up and try not to stress. Staying in Chi town overnight not an issue, but the chance of not having sleeper room for the SWC ride if they put us on the next one out, would really be a bummer. Much thanks

Appears that the CZ #5 (7/29) may have been held at CHI today as it departed 54 minutes late at 2:54 PM after LSL #49 (7/28) got in 4 hours and 49 minutes late at 2:34 PM. The SWC #5 (7/29) departed 24 mins late at 3:24 PM. So if your LSL is not super super late, they will hold for a little while for a connection. Good luck on the CSX Albany to Buffalo and NS Cleveland to Chicago segments.

Also good luck on CSX Buffalo to Cleveland. :-(

Based on recent trends, you're likely to be on time into Schenectady, get into Cleveland quite late, make up lots of time from Cleveland to South Bend, and then lose lots of time between South Bend and Chicago.

If something goes wrong between Cleveland and South Bend, then you'll be really late.

You very seldom make up much time between CLE and SOB. Perhaps a half hour at most. The main problem now is from Waterloo, Indiana to SOB where track work and signaling problems have gone on for several weeks and are likely to continue. It is true that the western trains have been held for the LSL and Capitol due to this problem.

They do try to hurry things along in Toledo, but with crew changes there, they seldom make up much time.

Try not to worry and have a good time. It is a guaranteed connection to western trains and Amtrak will put you up in Chicago if you miss them.

Yup, these days you don't make up time between CLE and SOB, you lose another hour or more due to significant single tracking with one track out of service for several tens of miles for track work.

Roughly speaking you lose 1.5 hours on CSX, about an hour between CLE and SOB, and then whatever happens from thence to Chicago, so that you land up with 2.5 - 3+ hours late into Chicago

It's just the way of the Late Shore Limited..

Yesterday's westbound LSL and CL did ok, at least in comparison to recent trips. LSL #49 (7/29) arrived 2:10 late at CHI after departing BUF 2:09 late and then making up time departing CLE 1:31 late. CL #29 (7/29) departed SOB only 21 minutes late and arrived 1:01 late at CHI. Unfortunately the eastbound LSL #48 and CL #30 (7/29) are still enroute running 2 to 3 hours late.

It is quite unpredictable how they'll do, but these days in general NS has been at least as big a disaster as CSX for that trains. That is why it racks up 2 to 4 hour delays instead of 1 to 1.5 hours.

Are the delays also on weekends? If I leave NYP on Sunday, what are the chances of track work delays early Monday morning?

The CSX delays seem to be completely consistent; they happen every single day of every week and amount to an hour or two every time, and this has been going on for years. CSX just isn't trying to dispatch the train on time.

The NS delays are more unpredictable (good days and bad days); you may be better off if you can avoid the periods of trackwork on NS.

Yeah. Though NS's new fangled dispatching automation system also seems to be causing problems by advising that fast freights be dispatched ahead of the LSL instead of behind it.

jis said:

Yeah. Though NS's new fangled dispatching automation system also seems to be causing problems by advising that fast freights be dispatched ahead of the LSL instead of behind it.

Click to expand...

That's actually illegal, y'know.

I had secondhand information from someone who was involved with programming a dispatching system for one of the Class Is; they had supposedly been told that the Class I had told them to program the system never to delay freight traffic to keep passenger trains on time.

That is actually illegal. It might well be worthwhile subpoenaing the designers of the dispatching system for NS to see if they were instructed to design an illegal dispatching system.

Yeah, might be worthwhile. It is possible that just raising the issue will cause them to review that aspect of the system, One never knows whether it is consciously designed to do so or it is doing so as an unintended consequence of some combination of other policies. I must admit that my day job of modeling business rules and their transformations to derived IT component policies is showing through here. Sometimes really bizarre and unexpected things happen

neroden said:

jis said:

Yeah. Though NS's new fangled dispatching automation system also seems to be causing problems by advising that fast freights be dispatched ahead of the LSL instead of behind it.

Click to expand...

That's actually illegal, y'know.

I had secondhand information from someone who was involved with programming a dispatching system for one of the Class Is; they had supposedly been told that the Class I had told them to program the system never to delay freight traffic to keep passenger trains on time.

That is actually illegal. It might well be worthwhile subpoenaing the designers of the dispatching system for NS to see if they were instructed to design an illegal dispatching system.

Click to expand...

Who would have standing besides Amtrak or the FRA to go to court to get a subpoena for the design specifications and code? My first thought was that the senior management at the Class 1s wouldn't be stupid enough to write such a rule into the design requirements or tell in writing the software engineers to put such rules into the code.
But, on second thought, the managers would be guys who wouldn't recognize or be able to read source code if someone put a printout (ancient concept I know) in front of them. People who should know better put all sorts of incriminating statements and orders in emails, text messages, facebook, etc because they somehow think no one can going to recover or read the contents in the future in a court proceeding or investigation. (See NJ and Bridgegate). So a subpoena or deposition might turn up such info if Amtrak were to get frustrated and go after one of the Class 1's dispatching software source code and data tables.

suzanne said:

Anyone know why LSL is late into Chicago for 7/29 arrival? We leave ALB tomorrow for LAX and a little worried about transfer.

Click to expand...

Following up on the OP, the westbound LSL #49(7/30) that departed NYP on Wednesday got to CHI 4 hours and 9 minutes late. Really late, but in time to make the connection to the SWC. CL #29 (7/30) arrived at CHI 4 hours and 6 minutes with both trains losing a lot of time between CLE and CHI.

afigg said:

Who would have standing besides Amtrak or the FRA to go to court to get a subpoena for the design specifications and code?

Click to expand...

Nobody.
Well, a commuter railroad which is in the same position as Amtrak, or one of the state governments which provides state-sponsored Amtrak service, but only if *their* services were being delayed. I think that's it.

I was thinking if bad *computer* dispatching of Amtrak becomes a recurring problem (so far this is a new thing), Amtrak would be the one who should subpoena the code.

My first thought was that the senior management at the Class 1s wouldn't be stupid enough to write such a rule into the design requirements or tell in writing the software engineers to put such rules into the code.

But, on second thought, the managers would be guys who wouldn't recognize or be able to read source code if someone put a printout (ancient concept I know) in front of them. People who should know better put all sorts of incriminating statements and orders in emails, text messages, facebook, etc because they somehow think no one can going to recover or read the contents in the future in a court proceeding or investigation. (See NJ and Bridgegate). So a subpoena or deposition might turn up such info if Amtrak were to get frustrated and go after one of the Class 1's dispatching software source code and data tables.

Click to expand...

Yeah. I'd particularly expect to see written documentation of this from the software designers' end, since they would not have been told that the instructions were illegal. (You might see an email which says something like "So, Bob, I wrote the software to prioritize passenger trains, but when I talked to XXX at Class I on the phone, he told us to prioritize freight trains...")
It's also perfectly possible that the dispatching system is programmed to behave illegally, but that the instructions to do so came from a middle manager who had no authority to give such instructions, (or indeed from a manager who is now gone) -- in which case finding out that the dispatching system is programmed this way might simply get it fixed.

On the other hand, maybe there's nothing wrong with the dispatching system and it is instructed to do the right thing. I can only report the infuriating thing I heard secondhand, which is hearsay. (It was unprompted, by someone who didn't know that I knew anything about the law on passenger train priority, which is why I remember it.)

Of course, the code itself would make it quite clear what trains the software was prioritizing, to any programmer who knew how to read it. So if bad computerized dispatching starts being a recurring problem, it could be quite easy to prove whether it was intentional or not, in contrast to the current situation where it's hard to prove intent with human dispatchers.

Typically, if the system is designed by a competent person or group, it is unlikely that there'd be anything to be find in the code. It would be more likely to be in what policies are administratively entered into the system when it is configured and set up. But I suppose I should stop there lest I start divulging too much about how such things work.

... I was wondering why someone would control that sort of directives hard at the code level rather than something you could modify at will from the front end.

jis said:

Typically, if the system is designed by a competent person or group, it is unlikely that there'd be anything to be fund in the code. It would be more to be in what policies are administratively entered into the system when it is configured and set up. But I suppose I should stop there lest I start divulging too much about how such things work.

Click to expand...

Of course, the dispatching software would be controlled by data or parameter tables of some sort. I have written enough software in enough languages to know how this is done. Hardwiring control values and thresholds in the code is not proper modern design. But you would need the source code, the plug-in component modules, and the parameter tables to determine exactly what is going on. And/Or get an executable version that runs on a simulator testbed and set up test scenarios to see what it does for freight versus passenger trains priorities under different conditions.

afigg said:

jis said:

Typically, if the system is designed by a competent person or group, it is unlikely that there'd be anything to be fund in the code. It would be more to be in what policies are administratively entered into the system when it is configured and set up. But I suppose I should stop there lest I start divulging too much about how such things work.

Click to expand...

Of course, the dispatching software would be controlled by data or parameter tables of some sort. I have written enough software in enough languages to know how this is done. Hardwiring control values and thresholds in the code is not proper modern design. But you would need the source code, the plug-in component modules, and the parameter tables to determine exactly what is going on. And/Or get an executable version that runs on a simulator testbed and set up test scenarios to see what it does for freight versus passenger trains priorities under different conditions.

Click to expand...

I would start with the latter and then work back from it. It is more than likely that the rules put in while setting things up has the net effect observed, and if that is the case changes in the rules is what one needs to figure out before wasting much time on code reading.

I was thinking that but when I last was considering computers as a career path C++ was in and Java was in its infancy.

Amtrak doesn't need to subpoena the code. Proving what is or isn't in the code is a total waste of time. All they need to do is keep their eyes open and document the delays where their trains don't get priority. When the dispute is to be decided, the delay is what's important - not whether a real live dispatcher or an automated system caused it.

jb

John Bobinyec said:

Amtrak doesn't need to subpoena the code. Proving what is or isn't in the code is a total waste of time. All they need to do is keep their eyes open and document the delays where their trains don't get priority. When the dispute is to be decided, the delay is what's important - not whether a real live dispatcher or an automated system caused it.

jb

Click to expand...

+1. Agree completely. At the end of the day it is the final result of whatever happens in the sausage factory that matters. One needs to look inside the sausage factory only if the final result is found to be Salmonella poisoning. Not otherwise. In a manner of speaking. If all that is in dispute is whether there is one sausage less per package that can be fixed by just changing the packaging, in a manner of speaking. Don't need to dig into how individual sausages are made.