speed test

On 9/18/2023 9:06 AM, Martin Brown wrote:
> Ouch! That is a royal PITA. Mine has to have its firmware updated every now and 
> then if a vulnerability is found and/or exploited but it boots in under a 
> minute from whatever internal SSD/memory stick it has.
> 
> It issues dire warnings about not switching it off during an update.

I wouldn't design any new application to run out of FLASH.
If the flash was fast enough for XIP, then you'd worry about
read wear (how do you recover if your media is "suspect"?)

And, RAM tends to be faster so you're going to WANT to transfer
your code into RAM, regardless...

If you have a decent size pipe, load the image over the wire.
This ensures you retain control over the product -- cuz it has
to "reauthorize" itself when it connects to the image server!
Particularly valuable if you treat "products as services" (the
new trend).

This lets you reduce your FLASH requirements to whatever is
available in an SoC and spend it doing POST/BIST instead of
*hoping* the application image will (always) fit in FLASH
(and never be corrupted).

[And, products that are "islands" will be deprecated as everything
WANTS to talk to other things... you just haven't, yet, figured out
*why*!]

mandag den 18. september 2023 kl. 20.51.22 UTC+2 skrev Don Y:
> On 9/18/2023 9:06 AM, Martin Brown wrote: 
> > Ouch! That is a royal PITA. Mine has to have its firmware updated every now and 
> > then if a vulnerability is found and/or exploited but it boots in under a 
> > minute from whatever internal SSD/memory stick it has. 
> > 
> > It issues dire warnings about not switching it off during an update.
> I wouldn't design any new application to run out of FLASH. 
> If the flash was fast enough for XIP, then you'd worry about 
> read wear (how do you recover if your media is "suspect"?) 

read wear? you have a single example of a flash with a limit on reads?
 
> And, RAM tends to be faster so you're going to WANT to transfer 
> your code into RAM, regardless... 

RAM is also more power hungry and expensive ....

On 9/18/2023 12:07 PM, Lasse Langwadt Christensen wrote:
> mandag den 18. september 2023 kl. 20.51.22 UTC+2 skrev Don Y:
>> On 9/18/2023 9:06 AM, Martin Brown wrote:
>>> Ouch! That is a royal PITA. Mine has to have its firmware updated every now and
>>> then if a vulnerability is found and/or exploited but it boots in under a
>>> minute from whatever internal SSD/memory stick it has.
>>>
>>> It issues dire warnings about not switching it off during an update.
>> I wouldn't design any new application to run out of FLASH.
>> If the flash was fast enough for XIP, then you'd worry about
>> read wear (how do you recover if your media is "suspect"?)
> 
> read wear? you have a single example of a flash with a limit on reads?

It's not a LIMIT but, rather, a corruption of adjacent cells
caused by read activity (technically, "read interference" but
it's effects can be persistent, negating the inherent value of
a "read only" memory)

>> And, RAM tends to be faster so you're going to WANT to transfer
>> your code into RAM, regardless...
> 
> RAM is also more power hungry and expensive ....

And more versatile.  The initialization code only needs to
run once and then the memory used for *it* can be used
as general purpose RAM.  The FLASH in which it resides
*must* always be set aside for that code cuz you've no
other place from which to get it!

mandag den 18. september 2023 kl. 21.20.10 UTC+2 skrev Don Y:
> On 9/18/2023 12:07 PM, Lasse Langwadt Christensen wrote: 
> > mandag den 18. september 2023 kl. 20.51.22 UTC+2 skrev Don Y: 
> >> On 9/18/2023 9:06 AM, Martin Brown wrote: 
> >>> Ouch! That is a royal PITA. Mine has to have its firmware updated every now and 
> >>> then if a vulnerability is found and/or exploited but it boots in under a 
> >>> minute from whatever internal SSD/memory stick it has. 
> >>> 
> >>> It issues dire warnings about not switching it off during an update. 
> >> I wouldn't design any new application to run out of FLASH. 
> >> If the flash was fast enough for XIP, then you'd worry about 
> >> read wear (how do you recover if your media is "suspect"?) 
> > 
> > read wear? you have a single example of a flash with a limit on reads?
> It's not a LIMIT but, rather, a corruption of adjacent cells 
> caused by read activity (technically, "read interference" but 
> it's effects can be persistent, negating the inherent value of 
> a "read only" memory)

only a potential issue when there is a mix of reads and writes

> >> And, RAM tends to be faster so you're going to WANT to transfer 
> >> your code into RAM, regardless... 
> > 
> > RAM is also more power hungry and expensive ....
> And more versatile. The initialization code only needs to 
> run once and then the memory used for *it* can be used 
> as general purpose RAM. The FLASH in which it resides 
> *must* always be set aside for that code cuz you've no 
> other place from which to get it!

so if the flash is fast enough the RAM is just added cost and power consumption for no benefit

On 9/18/2023 12:30 PM, sci.electronics.design wrote:
> mandag den 18. september 2023 kl. 21.20.10 UTC+2 skrev Don Y:
>> On 9/18/2023 12:07 PM, Lasse Langwadt Christensen wrote:
>>> mandag den 18. september 2023 kl. 20.51.22 UTC+2 skrev Don Y:
>>>> On 9/18/2023 9:06 AM, Martin Brown wrote:
>>>>> Ouch! That is a royal PITA. Mine has to have its firmware updated every now and
>>>>> then if a vulnerability is found and/or exploited but it boots in under a
>>>>> minute from whatever internal SSD/memory stick it has.
>>>>>
>>>>> It issues dire warnings about not switching it off during an update.
>>>> I wouldn't design any new application to run out of FLASH.
>>>> If the flash was fast enough for XIP, then you'd worry about
>>>> read wear (how do you recover if your media is "suspect"?)
>>>
>>> read wear? you have a single example of a flash with a limit on reads?
>> It's not a LIMIT but, rather, a corruption of adjacent cells
>> caused by read activity (technically, "read interference" but
>> it's effects can be persistent, negating the inherent value of
>> a "read only" memory)
> 
> only a potential issue when there is a mix of reads and writes

No.  *Write* disturb errors are a different kettle of fish.

>>>> And, RAM tends to be faster so you're going to WANT to transfer
>>>> your code into RAM, regardless...
>>>
>>> RAM is also more power hungry and expensive ....
>> And more versatile. The initialization code only needs to
>> run once and then the memory used for *it* can be used
>> as general purpose RAM. The FLASH in which it resides
>> *must* always be set aside for that code cuz you've no
>> other place from which to get it!
> 
> so if the flash is fast enough the RAM is just added cost and power consumption for no benefit

Flash must always be large enough to hold ALL of the code
that will EVER execute on the device.  E.g., POST, BIST,
application, etc.

The flash in my devices:
- disables the field
- sets the status indicator
- runs POST to verify the CPU, FLASH, RAM and NIC are operational
- downloads the diagnostic kernel into tested memory
- downloads the BIST for the FULL device (including field)
- runs the BIST for the field
- discards the BIST and loads the run-time kernel
- loads the application code and run-time diagnostics
- unloads the initialization code after it has initialized <whatever>

A fault that arises from, e.g., a read/write disturb on the RAM
causes the device (or portions of it) to reset with all of this
code simply reloaded -- not reFLASHED.

So, the FLASH is only used once per boot.  And, the total "program
image" can be many times larger than the SoC's FLASH.

On 17/09/2023 20:56, Don Y wrote:
> On 9/17/2023 7:37 AM, Martin Brown wrote:

>>> Most COs (in the places I've lived) have lines coming into a
>>> room in the basement, then up to a "wiring room" where all of
>>> the pairs are laid out (on punchdown blocks?).
>>
>> Is a CO what we would call a cabinet? Where the main trunk line back 
>> to the exchange is terminated and the local consumer circuits start?
> 
> Sorry.  "Central Office". It's close to what you would call an "exchange"
> but an "exchange" has also historically meant the first three digits of
> a (3+4) digit phone number.  Nowadays, large numbers of (copper)
> circuits are handled in a CO which may span multiple "phone number
> prefixes".

OK so our exchanges. Most here do handle one or perhaps 2 exchange codes 
although ISTR you can now port your phone number.

> Ah!  Well that's a shortsight!  I wonder how CATV and cell towers
> address power issues?  The towers seem to have tiny "support buildings"
> (if at all) barely larger than a clothes closet!

Nearby cell towers lasted about 20 hours and then stone dead. This 
quickly killed the remaining mobile phones that were not switched to 
airplane mode as they tried to contact more remote base stations.
> 
>> That service is Digital in Name Only or "DINO" it combines all the 
>> worst characteristics of VOIP (fails without power) without 
>> eliminating the pesky final mile of ageing copper that carries the 
>> VDSL signals.
> 
> Earlier versions (here) also had problems with acoustic modems.

Apart from Fax which is still used a lot in the NHS I don't think there 
are much if any acoustic modems in use today.
> 
>> POTS generally continues to work even when DSL is down (except if 
>> there is a fine break small enough for RF to jump the gap 
>> capacitively). Most importantly it still works when the mains has 
>> failed (and for a decent length of time too - exchanges have largish 
>> battery backup systems).
> 
> .. as long as the PHYSICAL line quality hasn't degraded.
> 
> Here, the CO is actually battery powered with the batteries
> continuously being charged (in the event mains power fails, a
> small, jet-powered genset picks up the load; in ages past,
> the billing computer might not be thusly backed up so
> "free long-distance"  :> )

Ours are battery backed up and I think mostly diesel generators although 
I have seen a demo hydrogen powered one once.
> 
> A cell phone subscriber could hedge his bet by picking two
> different carriers and HOPING they didn't share towers.

My wife and I are on different mobile networks precisely because where 
we live you don't always have good coverage from just one.
> 
> A CATV subscriber would be entirely at the mercy of the provider
> as only a single provider is allowed to operate in most
> areas (e.g., towns)

In Belgium we found the CATV and internet was more reliable than the 
local mains. You just needed a UPS to keep on working.
> 
>>>> are a bit unusual in that our lines are archaic "Exchange Only" 
>>>> lines with no cabinet between us and the exchange.
>>>
>>> So, any line repair/reconfiguration is done AT the CO?
>>
>> There is no CO the lines run right back to the exchange.
> 
> my CO = your exchange so, yes, any reconfiguration would be
> done back at the exchange/CO.
> 
> Seeing a wiring cabinet *in* a neighborhood is a new
> thing, for me.  Previously, I'd only seen them in businesses
> (PBX).

They are everywhere in the UK. Typically one per 100 or 200 houses.

>> That is the meaning of an exchange only line. They are a nightmare for 
>> VDSL operation because of the crosstalk they induce inside the 
>> exchange. The standard fix is that they install a new powered FTTC 
>> cabinet nearby and run anyone nearby taking the VDSL service to that.
> 
> I've not been *in* a CO/exchange for decades so can't speak to
> their current practices.
> 
> But, given TPC's tendency to roll out different solutions to
> problems, over time, I can only imagine it is a hodge-podge of
> kludges (that all "made sense", at some time)

It is a bit of an issue in rural locations. Back when non-ferrous metal 
prices were high there were people ripping out telco lines and railway 
signalling lines for their scrap metal value. Basically tie it to a land 
rover winch snip it some way away and go.
> 
>>> There's a large (20 sq ft) wiring cabinet at the entrance to our
>>> subdivisions that terminates all of the pairs from the CO *to*
>>> the pairs feeding the subscribers.  There is ALWAYS a telco
>>> service vehicle parked nearby "fixing" something (I'm guessing
>>> 200 homes in the subdivision?)
>>
>> That is about the size of our entire local exchange including its 
>> battery room. 
> 
> By 20 sq ft, I meant the panel is 4x5 ft (by about a foot deep?)

I meant 20' x 20' building (actually its more like 20'x30').
City ones are two storey and 10x bigger.

-- 
Martin Brown

On 9/19/2023 1:38 AM, Martin Brown wrote:
> On 17/09/2023 20:56, Don Y wrote:
>> On 9/17/2023 7:37 AM, Martin Brown wrote:
> 
>> Ah!  Well that's a shortsight!  I wonder how CATV and cell towers
>> address power issues?  The towers seem to have tiny "support buildings"
>> (if at all) barely larger than a clothes closet!
> 
> Nearby cell towers lasted about 20 hours and then stone dead. This quickly 
> killed the remaining mobile phones that were not switched to airplane mode as 
> they tried to contact more remote base stations.

Worth knowing.  I've not been "up close and personal" with any of the
cell towers -- but they don't look to have much supporting infrastructure
nearby.

>>> That service is Digital in Name Only or "DINO" it combines all the worst 
>>> characteristics of VOIP (fails without power) without eliminating the pesky 
>>> final mile of ageing copper that carries the VDSL signals.
>>
>> Earlier versions (here) also had problems with acoustic modems.
> 
> Apart from Fax which is still used a lot in the NHS I don't think there are 
> much if any acoustic modems in use today.

When I moved here, I used to run PEP to the local ISP.  But,
that predated DSL and was fast, for the time.

Now, I may move 20GB of traffic in a day -- EVERY day -- without
batting an eyelash!

>> A cell phone subscriber could hedge his bet by picking two
>> different carriers and HOPING they didn't share towers.
> 
> My wife and I are on different mobile networks precisely because where we live 
> you don't always have good coverage from just one.

Here, I think towers are often shared among providers (sometimes
the same kit; other times, different kit on the same physical
structures).

And, lots of MVNAs so you know they're essentially parasites...

>> A CATV subscriber would be entirely at the mercy of the provider
>> as only a single provider is allowed to operate in most
>> areas (e.g., towns)
> 
> In Belgium we found the CATV and internet was more reliable than the local 
> mains. You just needed a UPS to keep on working.

I hear horror stories of CATV customers railing against the company
over service quality issues.  But, we aren't big "video" consumers
(beyond movies from library, etc.) so we've never subscribed.

Of course, that's probably true of most "services"; they are accommodating
for "new subscribers".... then switch you over to "current subscriber"
SUPPORT staff (usually far less attentive and friendly!)

>>>>> are a bit unusual in that our lines are archaic "Exchange Only" lines with 
>>>>> no cabinet between us and the exchange.
>>>>
>>>> So, any line repair/reconfiguration is done AT the CO?
>>>
>>> There is no CO the lines run right back to the exchange.
>>
>> my CO = your exchange so, yes, any reconfiguration would be
>> done back at the exchange/CO.
>>
>> Seeing a wiring cabinet *in* a neighborhood is a new
>> thing, for me.  Previously, I'd only seen them in businesses
>> (PBX).
> 
> They are everywhere in the UK. Typically one per 100 or 200 houses.

Growing up was rural like your example so no real *place* for them.
No "planned subdivisions", etc.

I went to school in Boston and wandering around looking for
phone cabinets wasn't high on the list of "fun activities"!
My exposure, there, was within the school -- where it seemed
entirely logical that the 50 dorm rooms in this building should
have ALL of their telco wiring in one spot, etc.

>>> That is the meaning of an exchange only line. They are a nightmare for VDSL 
>>> operation because of the crosstalk they induce inside the exchange. The 
>>> standard fix is that they install a new powered FTTC cabinet nearby and run 
>>> anyone nearby taking the VDSL service to that.
>>
>> I've not been *in* a CO/exchange for decades so can't speak to
>> their current practices.
>>
>> But, given TPC's tendency to roll out different solutions to
>> problems, over time, I can only imagine it is a hodge-podge of
>> kludges (that all "made sense", at some time)
> 
> It is a bit of an issue in rural locations. Back when non-ferrous metal prices 
> were high there were people ripping out telco lines and railway signalling 
> lines for their scrap metal value. Basically tie it to a land rover winch snip 
> it some way away and go.

Here, it was the copper pipes on HVAC systems.  Businesses would
open their doors to discover their (roof mounted) HVAC system
had been cannabilized, overnight.  Not fun when your employees
don't have air conditioning (required for ~9 months of the year...
we turned ours on in February, this year and it's still 100F
in mid September...) and the "fix" is likely going to require
air-freighting in a new compressor...

Martin Brown wrote:
> On 12/09/2023 17:57, John Larkin wrote:
>> On Tue, 12 Sep 2023 15:33:31 +0100, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 12/09/2023 15:18, John Larkin wrote:
> 
>>>> This seems to be a trend, much faster internet than we signed up for,
>>>> same price. The backbone fibers must be moving petabits.
>>>
>>> I'm surprised that they upgrade you 10x for free. In the UK they
>>> invariably try to extract extra money out of you for such speed upgrades
>>> which means a lot of people are still on rather slow legacy speeds.
>>>
>>> Likewise with phone contracts they try to extract constant or ever
>>> increasing amounts of money from you by increasing mobile data.
>>
>> It seems like suppliers here are upgrading for free to keep up with
>> competition. We could use cable, a microwave dish, or a couple sources
>> for Gbit fiber.
> 
> That seems very socialist. It surely makes more sense for them to 
> extract at least some additional income for increasing your speed. UK 
> telcos are considerably more mercenary about upgrading their customers.
> 

They're hardly telcos in the US any longer. The increases in bandwidth
happen as vendors improve switching gear and they can't very well 
throttle it.

Some of it is a side effect of cell phones and trying to offer 5G to the 
home.

The interface between buyers and sellers is bizarre and they keep
getting faster almost on autopilot.

>> We had an AT&T internet connection over the traditional phone twisted
>> pairs, but it was slow and expensive and died when it rained. Comcast
>> threw in POTS telephone service for free when we got their internet
>> service. I unplugged the phones because all the calls were spam.
> 
> I presume the POTS phone service is actually a POTS connector on an all 
> digital VOIP service offered over their backhaul.

Yep. It's VoIP to a hybrid copper pair. Works well.

>  This is causing a lot 
> of trouble in the UK with BT rolling out "Digital Voice" over an 
> unwilling population of mostly elderly people who depend on features of 
> copper based POTS for living independently. Notably that POTS phones 
> still work if the mains fails and various alarms and care on call 
> services will only work correctly with a true copper physical line.
> 

Cell usually works even if the local grid is down. There are panic 
button services.

> ADSL in its various forms shouldn't be that unstable unless there is 
> something fundamentally wrong with the local wiring (as there is in my 
> village - no-one past me gets more than 2Mbps ADSL on copper).
> 

There's always something wrong with the local wiring, especially after
that stopped being a thing.


> However since I now have a fibre connection I don't care. The failing 
> junction box (think black plastic policeman's helmet with multicoloured 
> wire knitting and joints inside) is buried in the verge in front of my 
> house. If the water table rises it floods and shorts out circuits. When 
> the guys come to sort it out it sounds like maracas when they shake it!
> 
> In theory I think it is supposed to be water tight but in practice 
> rodents do for the catches or seals and after a few years it isn't.
> 

Strange; we found containers ( not sheet metal, something thicker - 
called 'em Bud boxes ) with O-ring seals and sealed connectors for  a 
pretty reasonable price retail years ago. Like tens of dollars.

They seem rat-proof to me.

-- 
Les Cargill

Martin Brown wrote:
> On 16/09/2023 12:19, John Larkin wrote:
>> On Sat, 16 Sep 2023 11:51:56 +0100, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
> 
>>> I haven't been able to find a picture of our underground configuration
>>> (it is quite rare now) but this one of a normal passive BT cabinet isn't
>>> too dissimilar if you image no supporting structure and the whole lot of
>>> multicoloured knitting stuffed randomly into a double width manhole.
>>>
>>> https://www.reddit.com/r/cablegore/comments/333ek9/inside_a_bt_telephone_cabinet/ 
>>>
> 
> That example is a textbook layout neat one. Ours looks like that one 
> after you have put a fork into it and and turned it over a few times!
> 
>> I collect pictures of disgusting wiring.
>>
>> https://www.dropbox.com/scl/fo/rdbz4ayuw0w60ch1f4dot/h?rlkey=k14c22nkj1leclay7itlpk28z&dl=0 
>>
> 
> It seems to me a miracle that telecoms stuff actually works!
> 

No miracle. It's the watchdog timers :)

-- 
Les Cargill

bitrex wrote:
> On 9/12/2023 10:18 AM, John Larkin wrote:
>> I signed up with Comcast for, I think, 30 megabit cable internet. I
>> had a service problem a while back so they upgraded "for free" to 50.
>> I just ran a speed test and it's 920+38 Mbits. This is with a CAT5
>> cable right from their modem.
>>
>> At work, we have a MonkeyBrains dish. We pay for 50+50 and get
>> 500+500.
>>
>> This seems to be a trend, much faster internet than we signed up for,
>> same price. The backbone fibers must be moving petabits.
> 
> A lot of those multi-hundred megabit connections will go to a wireless 
> router where all user devices are connected to it via 802.11n or 
> 802.11ac in a super-cluttered RF environment, and topping out at 50 or 
> 100 megabits throughput on a good day
> 

20 mbit is good enough for most things. I bought a cheap router last 
time, waiting for it to be inadequate and that day never came.

-- 
Les Cargill