@wawa

>ppc is the only platform this os and its software runs. its not some minor handicap

Currently it's not a handicap at all. Other matters are.

>that can be addresed later whe´n other problems are solved,

It has been said by Hyperion that it takes about two months to port AOS to any ISA, IIRC.

They welcome any third party to buy the port from them for a ISA&motherboard the third party wants.

> since this is a major limiting factor.

What does it limit currently? I'm not aware.

> ...if every work done till this point was done with almost non existant hardware in mind.

x5000 uses off-the-self components. I see no other alternative.

((To support all x86 motherboards (etc.), you need all of the money of Microsoft+x86 third parties and even then you fail like microsoft does. Same for linux. Apple does it better.))

Last edited by KimmoK on 11-Aug-2015 at 07:35 AM.
Last edited by KimmoK on 11-Aug-2015 at 07:34 AM.
Last edited by KimmoK on 11-Aug-2015 at 07:34 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Signal

"The strong point of Xena is the very fast rise and fall times of its pins, and it is edge triggered. A rising signal on a pin can trigger Xena to do something else (programmable) before a steady state is reached, and of course no need to wait for a falling edge (or the other way around, again programmable).

So, a detected input event can trigger a data transfer to Nemo much faster than the pin clocks could ever operate. It is NOT a magic chip (like op-amps) that can automatically speed up data buses.

It is what it is. That does not mean that people desiring it do something more should be treated badly or the inclusion of it on the board for their desired want was wrong, it only suggests that they require more information before delving into a project."


Nicely explained IMHO.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: @KimmoK I don't think so, since they have to engage some protocol for communicating. The XCore doesn't have a proper bus, but only I/O pins which should be programmed in some way. Quote: A-Eon website wrote: " It's an event-driven processor, which means it can respond immediately to events such as external signals, rather than having to wait on an interrupt. This makes it appropriate to true real-time functions. It has many input/output lines which are software configurable, making it ideal for ultra-low latency data sampling applications and extremely easy to turn into control hardware for... well, virtually anything. ... This is the kind of arrangement you'd expect for a board designed to use Xena for hardware control applications, where all the control logic is performed in software by Xena rather than in non-reusable custom ASIC hardware on the board, or using tricky programmable logic via an FPGA or similar."

But this means that the XCore is working alone, so without any "collaboration" with the CPU.

Quote:

Quote: cdimauro wrote: According to source which Michael posted, it's not a real PCIe slot. Quote: A-Eon website wrote: 'Xorro' will allow bridging Xena to external hardware for control purposes, to internal systems, or to other Xcore processors. ... Xena has 64 of these configurable I/O lines. In the AmigaOne X1000 we have one quarter of these connected to the CPU local bus for direct communication with the system, whilst the other three-quarters are connected directly to pins on the Xorro slot for communication with the outside world. JTAG connection for control and debugging of the XMOS silicon is accessible both through the CPU's GPIO (General Purpose Input/Output) lines and the Xorro interface.

OK, but the Xorro slot isn't a real PCIe one, as I already stated.

Quote:

Quote: cdimauro wrote: You can do the same by putting the XCore into a real PCIe card, connected to the computer of course. Just that no "real PCIe card" exists, where you can "putt the XCore into"...

True.

Quote:

Quote: cdimauro wrote: An FPGA with a sufficient amount of LE would have been much more interesting and useful. Apparently an xCORE implemented into a computer has advantages over FPGA, when it comes to using it for hardware control applications:

Quote:

Quote: A-Eon website wrote: "This is the kind of arrangement you'd expect for a board designed to use Xena for hardware control applications, where all the control logic is performed in software by Xena rather than in non-reusable custom ASIC hardware on the board, or using tricky programmable logic via an FPGA or similar."

The only advantage is represented by the fact that an XCore is easier to program, thanks to a more conventional ISA, compared to using VHDL/Verilog, which is much more difficult and specialized.

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: @Dandy You'll find a lot of fun transmitting the video signal from the loco to the monitor, since the XCore can transfer only 15MB/s to the CPU/memory. Not sure if the video signal from the loce actually has to be transmitted to the monitor via xCORE. There are possibly better ways of transmitting the signal - xCORE will possibly just be used to start/stop transmission...

That's absolutely fine, and basically it's its real domain.
Quote:

Regarding the transfer rate of 15 mB/s between cpu and xCORE: A-Eon stated that "In the AmigaOne X1000 we have one quarter of these connected to the CPU local bus for direct communication with the system". A web search for "local of the PA6T-1682M - transfer rates" brought me to the PWRficientTM Evaluation Kit. There I found some information regarding bus speeds and a schematic: Quote: PWRficientTM Evaluation Kit wrote: ... PROCESSOR: ... The PA6T-1682M includes a SoC providing 22 SERDES lanes allowing for up to 55 gigabits per second transfer rates between the SoC and external devices. ... MEMORY: ... high bandwidth Flash memory ... Autostore NOVRAM provides conventional SRAM fast access timing ... ARCHITECTURE: high-performance CPU and memory design ... The AOP4 processor’s SoC architecture includes a high-speed bus, capable of sustained block copy transfers exceeding 7.5 gigabytes per second, and a SERDES interface with 22 lanes, providing a peak bandwidth of over 55 gigabits per second. ... External I/O includes a VME interface, supporting VME64, 2eVME and 2eSST protocol, and sustained transfer rates exceeding 100 MB per second. ... According to the schematcs "Autostore NOVRAM" (which "provides conventional SRAM fast access timing") is connected to the "Local Bus". Static RAM (SRAM) has access times as low as 10 nanoseconds. This makes it hard to believe that memory access is really as slow as 15MB/s. The other transfer rates figure I found is related to "External I/O", connected to a so called "SERDES" lane and comes up with transfer rates exceeding 100 mB/s. "SERDES interface with 22 lanes, providing a peak bandwidth of over 55 gigabits per second"

I don't think that "local bus" (with quotes) on the Nemo's board description is the same PA6T's local bus, but some "insider" can help clarify it.

Anyway, if you take a look at the XCore architecture manual, you'll not find anything that sounds like the stuff that you reported.

In fact, if you want to implement some form of data bus, you have to implement it using yourself the I/O lines and a proper application running on a thread. Like XMOS did with the previously mentioned SDRAM controller (which was limited to 30MB/s with a 32-bit interface).

However, the coder which introduced support to the XCore has written a comment previously, in this thread: you can ask him how the "local bus" between the CPU and the XCore works. I don't think that there's any NDA violation for such technical information which is also useful/needed to coders which want to write something.
Quote:

Quote: cdimauro wrote: Exactly. ... Well, I had the xCORE's own RAM in mind here...

In this case you can run at full speed, but this memory is very limited in size and bandwidth too.
Quote:

Quote: cdimauro wrote: Something which can be realized with a better synergy of the XCore with the main system. The problem here is that the communication channel between the two is too much limited (see above: 15MB/s of bandwidth). I doubt this figure being correct, as I described above.

See above. And you can ask to the main coder for "Xena".
Quote:

Quote: cdimauro wrote: But nowadays you can have more spending much less. Yes - but "Amiga" is my hobby. If I would follow the "have more spending much less"-path I would not be here and the Amiga community would loose another member. I hope this is not what you desire...

Amiga is my hobby too, but I don't spend several Ks just for it.

I prefer to enjoy it using my existing hardware.
Quote:

Quote: cdimauro wrote: Consider, also, that SDKs for such boards usually support only Windows and/or Linux. You can have hard time trying to use something different. I'm not saying that it's not possible, but only that the experience can be worse. Yes, I considered that. But it seems as if Lyle Haze has put up an XMOS compiler that can be accessed from any network-connected AmigaOS machine - just that it is not publically available, because it's running on an Atom powered netbook: Lyle Haze posting regarding XMOS compiler

I saw, thanks.
Quote:

Furthermore I found a very interesting article by Lyle Haze about programming XENA: Writing apps for Xena

I've downloaded also the sample (BufferExample.lha), and from a first look it seems that it's only the CPU that can read or write the XCore's memory, and not viceversa. So, Xena seems to have no capability to access the system memory, starting the operation from itself.

If it's confirmed, it's even worse than what I expected.

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: @Dandy ... You can take them from third-parties, but a user wants them. ??? What do you mean with that? That I'm not a user (as I took 3rd party stuff)?

Sorry, absolutely not. I only mean that a user wants some stuff already installed from the very beginning, without having to do it himself.
Quote:

Quote: cdimauro wrote: Icaros (an AROS "distro"), for example, integrates a lot of stuff on top of AROS because users want and need them all (even more). Not sure how exactly Icaros works...

It's like a Linux distro: it includes a lot of software which is/can be useful for a plethora of users. And everything is also setup, to have a nice and working environment from the very beginning (after the installation).
Quote:

Quote: cdimauro wrote: However implementing things like 64-bit and SMP for AOS means losing its backward compatibility with existing applications (both PowerPC and 68K). Hmm - I got the impression that the Power Architecture compatible P.A. Semi Platform Processor is able to execute both - 32 Bit AND 64 Bit code: Quote: Power Architecture compatible P.A. Semi Platform Processor wrote: "This new P.A. Semi Platform Processor is Power Architecture compatible, and runs new or existing 32 or 64-bit PowerPC code."

Having a 64-bit architecture doesn't mean that you can use it. In fact, you can lose compatibility with the existing, 32-bit, applications, and o.ses too.

That's what happens with the AmigaOS4 and MorphOS: they run on 64-bit PowerPC chips, but only in 32-bit mode.

Quote:

Quote: cdimauro wrote: That's why you'll not see a 64-bit version of it, and only a multicore (not SMP) support will be added. Must have missed that implementation of 64 bitnes got removed from the OS4.2 roadmap. Do you have a link to this (bad) news?

The claimed "64-bit awareness" IMO is only a false statement to let peoples thinking about they are using 64 bits in some ways.

In reality I'm pretty sure that they are just using a PowerPC feature, which allows to map >4GB physical memory inside the usual 32-bit address space (4GB). Something like the famous x86's PAE which extended the physical addresses to 64GB (36 bits).
Quote:

Quote: cdimauro wrote: ... However in this case common sizes are measured in terms of hundred of GB, and not TB (too much expensive). Hmmm - actual offer of a PC/electronics reseller here in Cologne: 3000 gB Western Digital Red WD30EFRX.....................122,90 € 1000 gB Crucial CCT1000BX100SSD1 BX100 SSD.......357,90 € So 'real' (spinning) harddrives are a lot cheaper than SSDs - in this case the SSD is roughly 8.74 times more expensive per tB than a mechanical Harddisk...

Absolutely, but you don't have to buy a TB SSD: it's only needed for o.s. partition, and maybe for some small data partition (for frequently used datas).

A 120GB SSD if perfectly fine for this purpose. You can use a mechanical hard drive for all other data.

@KimmoK

Quote:

KimmoK wrote: @wawa >ppc is the only platform this os and its software runs. its not some minor handicap Currently it's not a handicap at all. Other matters are.

Like what?
Quote:

>that can be addresed later whe´n other problems are solved, It has been said by Hyperion that it takes about two months to port AOS to any ISA, IIRC.

AFAIK Hyperion hasn't the control/ownership of all o.s.'s components and/or licenses only for the PowerPC architecture.

So, a new ISA means also rewriting some parts and/or re-license the third-party components.
Quote:

((To support all x86 motherboards (etc.), you need all of the money of Microsoft+x86 third parties and even then you fail like microsoft does. Same for linux. Apple does it better.))

That's not true: you have STANDARDS for components/peripherals, and that's what you need to support.

AROS doesn't cover zillions of motherboards, but usually it's able to boot, at least, for this reason.

@cdimauro

>OK, but the Xorro slot isn't a real PCIe one, as I already stated.

xorro slot is physically: real PCIex1 + fake PCIex8 connectors in the same/single slot.

>>Currently it's not a handicap at all. Other matters are.
>Like what?

Lack of 3D drivers, lack of multicore support, lack of SW. etc...

>That's not true: you have STANDARDS for components/peripherals, and that's what you need to support.

if that would be true, we would not need driver updates. I would not need to hunt for drivers for my x86 boxes. Ever.

>AROS doesn't cover zillions of motherboards, but usually it's able to boot, at least, for this reason.

Right. That is not enough.
If that would be enough for MorphOS team (as an example), SAM460 support would have been released years ago and x5000 support would also be out allready. (IIRC, they plan to support only one motherboard for x86 at some point in future)
For high quality user experience one needs to do better use of the HW.

Last edited by KimmoK on 11-Aug-2015 at 11:32 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

Quote:

KimmoK wrote: @cdimauro >OK, but the Xorro slot isn't a real PCIe one, as I already stated. xorro slot is physically: real PCIex1 + fake PCIex8 connectors in the same/single slot.

But the real PCIe connector isn't part of the Xorro connector: it's independent. Right?
Quote:

>>Currently it's not a handicap at all. Other matters are. >Like what? Lack of 3D drivers, lack of multicore support, lack of SW. etc...

Lack of 64-bit also, but this means that you have to change your ISA.
Quote:

>That's not true: you have STANDARDS for components/peripherals, and that's what you need to support. if that would be true, we would not need driver updates. I would not need to hunt for drivers for my x86 boxes. Ever.

A driver implements a standard (or some standards).
Quote:

>AROS doesn't cover zillions of motherboards, but usually it's able to boot, at least, for this reason. Right. That is not enough. If that would be enough for MorphOS team (as an example), SAM460 support would have been released years ago and x5000 support would also be out allready. (IIRC, they plan to support only one motherboard for x86 at some point in future) For high quality user experience one needs to do better use of the HW.

That's another thing. But at the beginning, you need something which is working.

@cdimauro

>But the real PCIe connector isn't part of the Xorro connector: it's independent.

The card slot does have both connectors inline and the slot forms the xorro slot.
(nothing connects PCIex1 side to the xena untill the "bridgeboard" kind of card is in xorro slot)

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

Whatever made the Amiga great to begin with is dead. The MS-country is making sure that nothing from Europe will stand a chance and that includes AOS.

@cdimauro

Quote:

cdimauro wrote: @Dandy ... That's why you'll not see a 64-bit version of it, and only a multicore (not SMP) support will be added. ...

To answer this 'multicore/SMP'-part, I would like to cite Thomas Frieden:

Quote:

Thomas Frieden wrote about "Multicore and Amiga: Present and Future": ... "Where are we now? The development of SMP support has been separated into several distinctive steps. The first step was to rewrite the scheduler in C for easier accessibility. In the very end, this step might be reversed again, rewriting the then SMP capable scheduler back into assembly language. The second, more fundamental step was to decouple the scheduler from its current data structures. As you might know, ExecBase contains a lot of list for task that are ready, or waiting for a signal. This has now been achieved. The current development build uses a scheduler that no longer uses the original AmigaOS data structures, but a structure that is replicated for each core. The next step is to have each core in the development system (currently, the X1000) to run the scheduler. Test code will then start tasks on the different cores and see how they behave. We have already experimented with this and the results look promising. The tests basically showed that the lockout mechanism for Forbid works as planned. As a final step, the balancing will be introduced, which then finalizes the first implementation of SMP support in AmigaOS. ... Thomas Frieden, February 25, 2015"

You see, they are really implementing SMP - not just multicore...

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@cdimauro

Quote:

cdimauro wrote: @Dandy But this means that the XCore is working alone, so without any "collaboration" with the CPU.

Of course.
As far as I understood, the CPU (currently) is just required to load the xCORE-code to the xCORE tile(s) via the XORRO interface.

If there already was an AmigaOS-native xCORE-SDK, the CPU could furthermore be used to run this xCORE-SDK on the Amiga and to develop/debug the xCORE code.

Quote:

cdimauro wrote: OK, but the Xorro slot isn't a real PCIe one, as I already stated. ...

No, of course not.
The form of the connector is PCIe, but the function is XORRO.

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@Dandy

Until "SMP" is really there we all argue only about theories (how to do it?) and semantics (what is and what is not SMP?). Judging by ssolie´s comments in Mountain View, we will wait some more time for 4.2 (2016, 2017? Who knows? ).

@Dandy

Quote:

You see, they are really implementing SMP - not just multicore...

there have been many contradicting statements. the one you quote is just one of them. why argue, if none of us actually know for sure what are they "implementing" or not?

@cdimauro

Quote:

cdimauro wrote: @Dandy ... I don't think that "local bus" (with quotes) on the Nemo's board description is the same PA6T's local bus, but some "insider" can help clarify it.

Yes, that would indeed be interesting to know.

Quote:

cdimauro wrote: Anyway, if you take a look at the XCore architecture manual, you'll not find anything that sounds like the stuff that you reported.

I was referring to the "local bus" transfer rates of the PA6T.
Do you have a link to this "xCORE architecture manual"?

Quote:

cdimauro wrote: ... And you can ask to the main coder for "Xena".

Who is that?

Quote:

cdimauro wrote: ... ,but this memory is very limited in size and bandwidth too. ...

Hmmmm - back in the C64 days, 64 kilobytes of RAM was quite a lot. Just remember what all was possible with just 64 kB of memory...

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@cdimauro

Quote:

cdimauro wrote: @Dandy Sorry, absolutely not. I only mean that a user wants some stuff already installed from the very beginning, without having to do it himself.

Hmmm - back in the old days it was normal to have nothing installed.
On the Amiga, as well as on the old 8088 PCs, harddrives were luxury. there were many machines that just had floppy drives - the Amiga 3.5" and the PCs 5.25" floppy drives.
MsDos didn't come with network capability until version 6.22.
So back then it was common not to have "all inclusive" in the OS.
Initially AmigaOS even didn't have support for harddrives - you needed special software like "Boil3" to operate an harddrive.
While it is nice not having to install all and everything essential (like HD support), it can very well make sense having the possibility not to go online automatically upon each boot.
My Amiga only goes online when I start MiamiDX, Win goes online automatically when it boots.

Quote:

cdimauro wrote: ... And everything is also setup, to have a nice and working environment from the very beginning (after the installation).

I prefer just to install what I really need - not all the stuff I'd never touch anyway...

Quote:

cdimauro wrote: ... Having a 64-bit architecture doesn't mean that you can use it. In fact, you can lose compatibility with the existing, 32-bit, applications, and o.ses too.

If I have a 64-bit architecture that also can run 32 Bit apps, I would expect I can use it with an 32 Bit OS.

Quote:

cdimauro wrote: That's what happens with the AmigaOS4 and MorphOS: they run on 64-bit PowerPC chips, but only in 32-bit mode. ...

But on the other hand you benefit from the much higher frequency of the CPU, which should speed up the system significantly - even compared to my 68060@50 mHz...

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: @Dandy ... That's why you'll not see a 64-bit version of it, and only a multicore (not SMP) support will be added. ... To answer this 'multicore/SMP'-part, I would like to cite Thomas Frieden: Quote: Thomas Frieden wrote about "Multicore and Amiga: Present and Future": [...] Thomas Frieden, February 25, 2015[/i]" You see, they are really implementing SMP - not just multicore...

This "new" was already discussed here. Please, take a deep look at the discussion, because it deserves.

Anyway, a piece of the discussion was missing. I report again everything about that point:

"However implementing things like 64-bit and SMP for AOS means losing its backward compatibility with existing applications (both PowerPC and 68K). That's why you'll not see a 64-bit version of it, and only a multicore (not SMP) support will be added."

So, if they decided to implement SMP (which doesn't seems to be a real SMP: read the above discussion), it means that they are sacrificing the backward compatibility (in some measure: it depends by the kind of multicore implementation, and by the single application), as I already reported several times.

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: @Dandy But this means that the XCore is working alone, so without any "collaboration" with the CPU. Of course. As far as I understood, the CPU (currently) is just required to load the xCORE-code to the xCORE tile(s) via the XORRO interface. If there already was an AmigaOS-native xCORE-SDK, the CPU could furthermore be used to run this xCORE-SDK on the Amiga and to develop/debug the xCORE code.

Frankly speaking, if this is the case I don't see any advantage of this solution over the USB-ones already available.

BTW, USB can generate interrupt to the CPU, if I remember correctly.

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: Anyway, if you take a look at the XCore architecture manual, you'll not find anything that sounds like the stuff that you reported. I was referring to the "local bus" transfer rates of the PA6T.

OK, but it seems that it isn't the used for interfacing it with the XCore.
Quote:

Do you have a link to this "xCORE architecture manual"?

Some time ago I downloaded a file which is called "XM-000324-RF-1.pdf" from the XMOS site.
Quote:

Quote: cdimauro wrote: ... And you can ask to the main coder for "Xena". Who is that?

lylehaze. He already posted something here.
Quote:

Quote: cdimauro wrote: ... ,but this memory is very limited in size and bandwidth too. ... Hmmmm - back in the C64 days, 64 kilobytes of RAM was quite a lot. Just remember what all was possible with just 64 kB of memory...

But that was more than 30 years ago. Now we have MUCH more resources.

@Dandy

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: @Dandy Sorry, absolutely not. I only mean that a user wants some stuff already installed from the very beginning, without having to do it himself. Hmmm - back in the old days it was normal to have nothing installed. On the Amiga, as well as on the old 8088 PCs, harddrives were luxury. there were many machines that just had floppy drives - the Amiga 3.5" and the PCs 5.25" floppy drives. MsDos didn't come with network capability until version 6.22. So back then it was common not to have "all inclusive" in the OS. Initially AmigaOS even didn't have support for harddrives - you needed special software like "Boil3" to operate an harddrive.

OK, but that was a long time ago, and nowadays we have plenty of resources available (and mostly not used).
Quote:

While it is nice not having to install all and everything essential (like HD support), it can very well make sense having the possibility not to go online automatically upon each boot. My Amiga only goes online when I start MiamiDX, Win goes online automatically when it boots.

I agree. Maybe there's some way to avoid it, other than physically disconnecting the cable.
Quote:

Quote: cdimauro wrote: ... And everything is also setup, to have a nice and working environment from the very beginning (after the installation). I prefer just to install what I really need - not all the stuff I'd never touch anyway...

I prefer to install everything, instead of losing time cherry-picking what I need. Space storage is not a problem anymore.
Quote:

Quote: cdimauro wrote: ... Having a 64-bit architecture doesn't mean that you can use it. In fact, you can lose compatibility with the existing, 32-bit, applications, and o.ses too. If I have a 64-bit architecture that also can run 32 Bit apps, I would expect I can use it with an 32 Bit OS.

It depends by the o.s.. We were talking about an Amiga/like o.s., so in this case it applies what I've already written.
Quote:

Quote: cdimauro wrote: That's what happens with the AmigaOS4 and MorphOS: they run on 64-bit PowerPC chips, but only in 32-bit mode. ... But on the other hand you benefit from the much higher frequency of the CPU, which should speed up the system significantly - even compared to my 68060@50 mHz...

True.

BTW, a PowerPC running in 64-mode has a speed penalty on average, due to the increased pointer sizes, and long size too (but it depends on the ABI).

EDIT. Correct PC with PowerPC in the last sentence.

Last edited by cdimauro on 27-Aug-2015 at 05:16 PM.