From: Jonathan Morton <chromatix99@gmail.com>
To: Aaron Wood <woody77@gmail.com>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] Comcast upped service levels -> WNDR3800 can't cope...
Date: Sat, 30 Aug 2014 21:01:46 +0300 [thread overview]
Message-ID: <E763DC94-378A-4CD8-B7C4-6E4517C77B0C@gmail.com> (raw)
In-Reply-To: <CALQXh-OQ0u-H3XqqigB5Og3uM0Q5EBSyF=dQV7R0i1v=MF+5-A@mail.gmail.com>
On 30 Aug, 2014, at 8:19 pm, Aaron Wood wrote:
> Do you think this is a limitation of MIPS as a whole, or just the particular MIPS cores in use on these platforms?
There were historically a great many MIPS designs. Several of the high-end designs were 64-bit and used in famous workstations. The one we see in CPE today, however, is the MIPS equivalent of the AMD Geode, based on an old version of the MIPS architecture, and further crippled by embedded-style hardware choices. It would have been a good CPU in 1989, considering that it would have competed against the 486 in the PC space, but it wouldn't have been hobbled by a 16-bit memory bus back then.
I'm not sure how much effort is going into improving the embeddable versions of MIPS cores, but certainly ARM seems to be a more active participant in the embedded space. Their current range of embeddable cores scales from the Cortex-M0 (whose chief selling point is that it takes only a fraction of a square millimetre of die space) to some quite decent 64-bit multicore CPUs (which AMD is developing a server platform for), with a number of intermediate points along that continuum catered for.
So if a particular core works but proves to have inadequate performance, a better one can be integrated into the next version of the hardware, without any risk of having to rewrite all the software. That future-proofing is probably important to manufacturers, and isn't very obviously available with MIPS cores.
I wouldn't be surprised to see something like a Cortex-A5, or possibly even a multicore Cortex-A7 in CPE. These are capable of running conventional multitasking OSes like Linux (and hence OpenWRT), and have a lot of fully-mature toolchain support. But perhaps they would leave out the FPU, or configure only the most basic type of FPU (VFPv3-D16), to save money compared to the NEON unit you'd normally find in a smartphone.
- Jonathan Morton
next prev parent reply other threads:[~2014-08-30 18:01 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-29 16:57 [Cerowrt-devel] " Aaron Wood
2014-08-29 17:03 ` [Cerowrt-devel] [Bloat] " Rick Jones
2014-08-29 17:15 ` Jonathan Morton
2014-08-29 17:19 ` Jonathan Morton
2014-08-29 17:25 ` Sebastian Moeller
2014-08-29 18:06 ` Dave Taht
2014-08-30 11:02 ` Jonathan Morton
2014-08-30 13:03 ` Toke Høiland-Jørgensen
2014-08-30 17:33 ` Jonathan Morton
2014-08-30 20:47 ` Jonathan Morton
2014-08-30 22:30 ` Dave Taht
2014-08-31 10:18 ` Jonathan Morton
2014-08-31 10:21 ` Toke Høiland-Jørgensen
2014-09-01 17:01 ` Dave Taht
2014-09-01 18:06 ` Jonathan Morton
2014-09-01 18:32 ` Dave Taht
2014-09-01 20:25 ` Aaron Wood
2014-09-01 21:43 ` Jonathan Morton
2014-09-01 22:14 ` Aaron Wood
2014-09-02 9:09 ` David Lang
2014-09-02 9:27 ` Jonathan Morton
2014-09-02 10:05 ` Joel Wirāmu Pauling
2014-09-02 10:05 ` Joel Wirāmu Pauling
2014-09-03 6:15 ` Aaron Wood
2014-09-03 6:36 ` David Lang
2014-09-03 11:08 ` Jonathan Morton
2014-09-03 15:12 ` Aaron Wood
2014-09-03 19:22 ` Sebastian Moeller
2014-09-03 19:30 ` Dave Taht
2014-09-03 23:17 ` Bill Ver Steeg (versteb)
2014-09-04 0:33 ` Dave Taht
2014-09-04 3:36 ` Jonathan Morton
2014-09-04 14:05 ` Bill Ver Steeg (versteb)
2014-09-04 15:10 ` Michael Richardson
2014-09-04 7:04 ` Sebastian Moeller
2014-09-04 11:15 ` Jonathan Morton
2014-09-04 11:23 ` Sebastian Moeller
2014-09-02 8:55 ` Sebastian Moeller
2014-09-02 13:40 ` Jonathan Morton
2014-09-02 13:49 ` Sujith Manoharan
2014-09-02 15:37 ` Dave Taht
2014-09-02 15:47 ` Jonathan Morton
2014-09-02 15:57 ` Sujith Manoharan
2014-09-02 17:36 ` Jonathan Morton
2014-09-02 17:41 ` Dave Taht
2014-09-02 18:28 ` Jonathan Morton
2014-09-03 11:04 ` Jonathan Morton
2014-08-30 21:53 ` Stephen Hemminger
2014-08-30 11:14 ` Jonathan Morton
2014-08-30 17:19 ` Aaron Wood
2014-08-30 18:01 ` Jonathan Morton [this message]
2014-08-30 18:21 ` Sebastian Moeller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E763DC94-378A-4CD8-B7C4-6E4517C77B0C@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=woody77@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox