• Re: HUB Query

    From Avon@21:1/101 to Oli on Friday, May 14, 2021 12:12:43
    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)
  • From Oli@21:3/102 to Avon on Friday, May 14, 2021 08:38:48
    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)
  • From Al@21:4/106.1 to Oli on Friday, May 14, 2021 00:51:19
    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)
  • From Oli@21:3/102 to Al on Friday, May 14, 2021 10:21:22
    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)
  • From Al@21:4/106.1 to Oli on Friday, May 14, 2021 02:55:47
    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)
  • From Al@21:4/106.1 to Oli on Friday, May 14, 2021 03:38:55
    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)
  • From Oli@21:3/102 to Al on Friday, May 14, 2021 13:07:17
    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)
  • From Al@21:4/106.1 to Oli on Friday, May 14, 2021 17:32:39
    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)
  • From Al@21:4/106.1 to Oli on Friday, May 14, 2021 20:25:45
    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)
  • From Oli@21:3/102 to Al on Saturday, May 15, 2021 07:11:15
    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)
  • From Al@21:4/106.1 to Oli on Saturday, May 15, 2021 01:20:32
    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)