I wish to hear the answer from QSSL, which is very simple, either “Yes, it
works like this!” or “No, it works like this …”. Please don’t leave us
in this uncertainty 
If I port to QNX 6, will I get the same problem?
I know there’s work being done for QNX6 to support larger than 4Gb RAM. Not
sure about status, apparently there’s something already, since it was
mentioned in one of press releases about PPC support. Data type for physical
address is 64 bit …
- igor
“Johannes” <jsukamtoh@yahoo.com> wrote in message
news:9p0ede$6pv$1@inn.qnx.com…
I wish to hear the answer from QSSL, which is very simple, either “Yes, it
works like this!” or “No, it works like this …”. Please don’t leave
us
in this uncertainty >If I port to QNX 6, will I get the same problem?
Best to post on one of the QNX hosted newsgroups. qdn.public.qnx4 would
probably be a good pick.
Johannes <jsukamtoh@yahoo.com> wrote:
I wish to hear the answer from QSSL, which is very simple, either “Yes, it
works like this!” or “No, it works like this …”. Please don’t leave us
in this uncertainty >If I port to QNX 6, will I get the same problem?
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Is that mean I have to wait for the 64 bit Intel processor to be released
first?
“Igor Kovalenko” <kovalenko@home.com> wrote in message
news:9p0pur$d2f$1@inn.qnx.com…
I know there’s work being done for QNX6 to support larger than 4Gb RAM.
Not
sure about status, apparently there’s something already, since it was
mentioned in one of press releases about PPC support. Data type for
physical
address is 64 bit …
- igor
“Johannes” <> jsukamtoh@yahoo.com> > wrote in message
news:9p0ede$6pv$> 1@inn.qnx.com> …
I wish to hear the answer from QSSL, which is very simple, either “Yes,
it
works like this!” or “No, it works like this …”. Please don’t leave
us
in this uncertainty >If I port to QNX 6, will I get the same problem?
Johannes <jsukamtoh@yahoo.com> wrote:
I wish to hear the answer from QSSL, which is very simple, either “Yes, it
works like this!” or “No, it works like this …”. Please don’t leave us
in this uncertainty >
QNX4 is designed for realtime & embedded systems. It has always had
problems with scalability at the large end of the scale – that was
never its target market. The high-end scalability has improved over
time, but, as you are finding out, it is still limitted. Earlier
version of QNX 4.2 limitted the virtual address space to 256M, so the
4G limit you are hitting (from previous thread) is an improvement on
the high-end scalability. There used to be other issues, and there
are still other scalability limitations – I don’t think it will support
more than 2000 process table entries, for instance.
If I port to QNX 6, will I get the same problem?
No, you shouldn’t. Part of the re-design of QNX 6 involved planning for
full scalability right up to the very large systems.
-David
QNX Training Services
dagibbs@qnx.com
THANKS! At last I have the answer. Looks like I have to migrate to QNX 6
asap!
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:9pkogm$n7s$1@nntp.qnx.com…
Johannes <> jsukamtoh@yahoo.com> > wrote:
I wish to hear the answer from QSSL, which is very simple, either “Yes,
it
works like this!” or “No, it works like this …”. Please don’t leave
us
in this uncertainty >QNX4 is designed for realtime & embedded systems. It has always had
problems with scalability at the large end of the scale – that was
never its target market. The high-end scalability has improved over
time, but, as you are finding out, it is still limitted. Earlier
version of QNX 4.2 limitted the virtual address space to 256M, so the
4G limit you are hitting (from previous thread) is an improvement on
the high-end scalability. There used to be other issues, and there
are still other scalability limitations – I don’t think it will support
more than 2000 process table entries, for instance.If I port to QNX 6, will I get the same problem?
No, you shouldn’t. Part of the re-design of QNX 6 involved planning for
full scalability right up to the very large systems.-David
QNX Training Services
dagibbs@qnx.com
David,
Does QNX 6 support more than 4G of physical memory?
Is there any plan to support it soon?
-Tony
David Gibbs <dagibbs@qnx.com> wrote in message
news:9pkogm$n7s$1@nntp.qnx.com…
Johannes <> jsukamtoh@yahoo.com> > wrote:
I wish to hear the answer from QSSL, which is very simple, either “Yes,
it
works like this!” or “No, it works like this …”. Please don’t leave
us
in this uncertainty >QNX4 is designed for realtime & embedded systems. It has always had
problems with scalability at the large end of the scale – that was
never its target market. The high-end scalability has improved over
time, but, as you are finding out, it is still limitted. Earlier
version of QNX 4.2 limitted the virtual address space to 256M, so the
4G limit you are hitting (from previous thread) is an improvement on
the high-end scalability. There used to be other issues, and there
are still other scalability limitations – I don’t think it will support
more than 2000 process table entries, for instance.If I port to QNX 6, will I get the same problem?
No, you shouldn’t. Part of the re-design of QNX 6 involved planning for
full scalability right up to the very large systems.-David
QNX Training Services
dagibbs@qnx.com
TLee <tonylee@ambernetworks.com> wrote:
David,
Does QNX 6 support more than 4G of physical memory?
My understanding is that QNX6 doesn’t currently run on any board/system
that has more than 4G of physical address range – so no. (In fact,
you couldn’t even get 4G of RAM, as you’ll need address space for I/O
cards, boot ROM/Flash/BIOS, etc.)
Is there any plan to support it soon?
Again, my understanding is that as demand for a board that requires it
comes up, we’ll support it. It is architected for this – take a look
at routines like mmap_device_memory() and you’ll see that the offsets for
physical addresses are 64-bit values. This was done because it was expected
we’d need to scale to that range eventually.
As to soon? I can’t say.
-David
QNX Training Services
dagibbs@qnx.com
David Gibbs <dagibbs@qnx.com> wrote:
TLee <> tonylee@ambernetworks.com> > wrote:
David,
Does QNX 6 support more than 4G of physical memory?My understanding is that QNX6 doesn’t currently run on any board/system
that has more than 4G of physical address range – so no. (In fact,
you couldn’t even get 4G of RAM, as you’ll need address space for I/O
cards, boot ROM/Flash/BIOS, etc.)
Actually, there is a PPC7450 based board that supports a 64bit addressing
scheme. So it will support more then 4G of physical memory (AFAIK). There
is a press release about it with the Network Platform PRs.
chris
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
David,
I agree with Chris.
Xeon processor support 64GBytes of physical memory with 36bits address
line.
Our preview system come with 512MB. Current design with 2GB. It should
be
very soon the 4GB limit become huge problem (just like 640K was huge problem
15
years ago).
If your at designing a system that manage few millions users each has
1-10 IP sessions and each session can have number of tunnel and everyone of
the
session/tunnel require a few hundreds bytes of state info.
It doesn’t take much to go pass 4 GB.
-Tony
Chris McKillop <cdm@qnx.com> wrote in message
news:9q58ut$1ha$1@nntp.qnx.com…
David Gibbs <> dagibbs@qnx.com> > wrote:
TLee <> tonylee@ambernetworks.com> > wrote:
David,
Does QNX 6 support more than 4G of physical memory?My understanding is that QNX6 doesn’t currently run on any board/system
that has more than 4G of physical address range – so no. (In fact,
you couldn’t even get 4G of RAM, as you’ll need address space for I/O
cards, boot ROM/Flash/BIOS, etc.)
Actually, there is a PPC7450 based board that supports a 64bit addressing
scheme. So it will support more then 4G of physical memory (AFAIK).
There
is a press release about it with the Network Platform PRs.chris
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL