On 13 May 2021 at 02:59p, Oli pondered and said...

NET 2 (you :) is currently on Mystic but my desire would be to shift o this and run the same software as 1,3, and 4.

Why?

Standardization. If things are mostly the same between HUBs in terms of how they are set up and run.... It makes for easier debugging, changes to config and reports generated.

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Avon wrote (2021-05-14):

On 13 May 2021 at 02:59p, Oli pondered and said...

NET 2 (you :) is currently on Mystic but my desire would be to
shift o this and run the same software as 1,3, and 4.

Why?

Standardization. If things are mostly the same between HUBs in terms of
how they are set up and run.... It makes for easier debugging, changes to config and reports generated.

I thought standardization is for enabling different FTN programs talk to each other. By using diverse software, standardization problems will show up more likely.

Btw, hpt still has a standardization problem with the JAM ;) (AFAIK) and doesn't have stable releases.

I know, I just picked two aspects and that there others things to consider (like open source, fixability, maintenance, ...).

---
* Origin: . (21:3/102)

Re: HUB Query
By: Oli to Avon on Fri May 14 2021 08:38 am

Btw, hpt still has a standardization problem with the JAM ;) (AFAIK) and doesn't have stable releases.

It seems to have a problem with squish too.. recently it seems to always use even seconds. Maybe that solves the problem, I don't know.

Ttyl :-),
Al

... Reality is for those who can't handle computers.
--- SBBSecho 3.14-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

Al wrote (2021-05-14):

Re: HUB Query
By: Oli to Avon on Fri May 14 2021 08:38 am

Btw, hpt still has a standardization problem with the JAM ;)
(AFAIK) and doesn't have stable releases.

It seems to have a problem with squish too.. recently it seems to always use even seconds. Maybe that solves the problem, I don't know.

Oh noooo! (exploding like a Lemming).

Good to know, I just assumed it was fixed as there was a commit for the bug. Are you're sure that it is not your uplink(s) that modifies the time? (doesn't look like it as the mails from every network look fine as far as I can tell).

I will test it again, when I find the time over the weekend.

---
* Origin: . (21:3/102)

Re: HUB Query
By: Oli to Al on Fri May 14 2021 10:21 am

Oh noooo! (exploding like a Lemming).

Nothing here is hurting. My Squish bases all seem to be fine.

Good to know, I just assumed it was fixed as there was a commit for the bug. Are you're sure that it is not your uplink(s) that modifies the time? (doesn't look like it as the mails from every network look fine as far as I can tell).

It may be fixed. I don't understand that 2 second issue.

I just took a long walk through the cooking area and all the messages here report even seconds for the message date as well as the time written here.

I don't know if that is true of packets that leave here for other nodes.

I'll let some stuff collect here for a bit and inspect the time on the incoming packets vs what my msgbase says.

Ttyl :-),
Al

... 1st rule of intelligent tinkering - save all the parts
--- SBBSecho 3.14-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

Re: HUB Query
By: Al to Oli on Fri May 14 2021 02:55 am

I'll let some stuff collect here for a bit and inspect the time on the incoming packets vs what my msgbase says.

I've just had a quick look at some incoming packets, at the time and some of them did have odd seconds, but the message stored in the message base has even seconds.

I only had a quick look and I did see some messages that had odd seconds but most of them were even.

There is some stuff sitting in my outbound waiting for pick up so I had a quick look at the time on them and some did also have odd numbers for the seconds. Most were even though, just as I see in my inbound.

So it seems.. after having a look at those inbound/outbound packets that the seconds are passed on as is, and that messages stored in my squish bases are stored with even seconds.

I don't know if that is an issue. I find it odd but I don't know if that is an issue.

Ttyl :-),
Al

... Put on your seatbelt - I'm gonna try something new!
--- SBBSecho 3.14-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

Al wrote (2021-05-14):

So it seems.. after having a look at those inbound/outbound packets that the seconds are passed on as is, and that messages stored in my squish bases are stored with even seconds

My bad. DOS timedate has only a 2-second resolution. Which mean it's always stored with even seconds. Additionally the original time from the message is stored as a string. On export / rescan this __ftscdate field should be used (if there is one). This is what the bug fix implemented. The message editors usually display the DOS timedate, which means even seconds.

I don't know if that is an issue. I find it odd but I don't know if that
is an issue.

I think it's perfectly fine and to be expected (for a Squish message base). I find the 2-second DOS time issue odd too though.

---
* Origin: . (21:3/102)

Re: HUB Query
By: Oli to Al on Fri May 14 2021 01:07 pm

I think it's perfectly fine and to be expected (for a Squish message base). I find the 2-second DOS time issue odd too though.

Yes, I think it's just the way golded displays the time with squish bases.

Ttyl :-),
Al

... Should I or shouldn't I?... Too late, I did!
--- SBBSecho 3.14-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

Re: HUB Query
By: Oli to Al on Fri May 14 2021 01:07 pm

I think it's perfectly fine and to be expected (for a Squish message base). I find the 2-second DOS time issue odd too though.

Just as an experiment I switched a few of my fsxNet areas to jam and did a rescan on those areas. All of the dates that golded displayed all had even seconds.

I think what I am seeing here is because of the way golded displays the date.

I don't see that on Synchronet. The dates have a mix of odd and even seconds in the time.

Ttyl :-),
Al

... People say I'm apathetic, but I don't care.
--- SBBSecho 3.14-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

Al wrote (2021-05-14):

I think it's perfectly fine and to be expected (for a Squish message
base). I find the 2-second DOS time issue odd too though.

Just as an experiment I switched a few of my fsxNet areas to jam and did
a rescan on those areas. All of the dates that golded displayed all had even seconds.

Where did you get the rescan from? If it's from your Squish base, you should get 1-second accuracy. If you rescanned from Hub 1, 3 or 4 (or any other node that uses hpt with JAM) you would get 2-second resolution, because of a bug / design flaw in husky's smapi. hpt mangles the time when storing messages in a JAM base and they are lost forever. Which means the first time you receive the mail from your hub it has the correct time. If you do a rescan, all odd seconds have been changed to even seconds.

I think what I am seeing here is because of the way golded displays the date.

Golded does display time accurately down to the second (with JAM). The odd seconds (as in least significant bit) have been stripped somewhere else.

---
* Origin: . (21:3/102)

Re: HUB Query
By: Oli to Al on Sat May 15 2021 07:11 am

Where did you get the rescan from? If it's from your Squish base, you should get 1-second accuracy. If you rescanned from Hub 1, 3 or 4 (or any other node that uses hpt with JAM) you would get 2-second resolution, because of a bug / design flaw in husky's smapi. hpt mangles the time when storing messages in a JAM base and they are lost forever. Which means the first time you receive the mail from your hub it has the correct time. If you do a rescan, all odd seconds have been changed to even seconds.

I rescanned from hub 1 and 4, so maybe that is why.

I'll try that again from a link running something else in some out of the way areas.

Golded does display time accurately down to the second (with JAM). The odd seconds (as in least significant bit) have been stripped somewhere else.

That's too bad.. :(

Ttyl :-),
Al

... Scotty, beam me to the Bahamas.
--- SBBSecho 3.14-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)